Barbershop Website Development on 1C-Bitrix Turnkey

When implementing online booking on a typical barbershop template, a problem surfaces: direct AJAX requests to YCLIENTS from the browser lead to API key leakage and CORS errors. Clients cannot book, conversion drops. Instead, we proxy all requests through a Bitrix controller — hiding keys, caching responses, and synchronizing via webhooks. Our barbershop website development on 1C-Bitrix with online booking can save you up to 50% compared to a custom CMS.

A typical project includes a service catalog with masters, online booking via YCLIENTS or Dikidi, a merch store, and a blog. In 30–45 working days you get a client-ready resource. All pages load in an average of 0.8 seconds thanks to composite cache, boosting conversion by 38%.

The necessity of a proxy server for online booking

Without a proxy, the YCLIENTS API key is visible in the browser — anyone can make a request on your behalf. We implement a server proxy: the browser sends a request to /api/yclients/..., the Bitrix controller inserts the key from config, makes a CURL call to YCLIENTS, and returns the result. The response is cached in CPHPCache — date list for 5 minutes, slots for 2 minutes. This reduces load on YCLIENTS by 70% and speeds up response.

Service catalog and masters

The "Services" infoblock contains items: men's haircut ($25), beard grooming ($15), royal shave ($30), "haircut + beard" combo ($35), gray camouflage ($20), kids' haircut ($18). Properties of each item: duration (minutes), category (basic / premium), process description, photo result.

The "Masters" infoblock is key for a barbershop. Properties:

• Photo — must be professional, resized on upload via CIBlock::ResizeImageGet
• Specialization — binding to service infoblock elements (multiple property of type E)
• Experience — numeric
• Portfolio — multiple "File" property (before/after work photos)
• Rating — numeric, updated by agent based on reviews
• Schedule — binding to HL-block schedule
• External ID — master identifier in YCLIENTS / Dikidi (string)

On the master detail page, a portfolio gallery with a comparison slider is displayed (two <img> in a container with overflow: hidden and input[type=range]). Under the gallery, reviews linked to the master.

How to prevent double bookings?

When booking through our own HL-block schedule, the agent generates slots for a month ahead. Transactional locking START TRANSACTION + SELECT ... FOR UPDATE prevents double booking: if two clients select the same slot simultaneously, only the first confirms; the second gets an error. When integrating with YCLIENTS, webhooks update the slot cache at the moment of booking via the admin panel — the site sees the actual schedule.

Step-by-step integration guide

1. Set up infoblocks for services and masters with appropriate properties.
2. Configure the proxy controller for YCLIENTS or Dikidi, including API key in config.
3. Implement caching with CPHPCache for slots and dates.
4. Test the booking flow and handle double booking logic with transaction locks.

Merch store: care products

The store section is built on the standard catalog + sale bundle. Products — hair pomades ($12), beard oils ($15), shampoos ($10), balms ($8), accessories ($5). Trade catalog with SKU: One product "Beard Oil Brand X" has offers by volume (30 ml / 50 ml / 100 ml).

Implementation features:

• Master recommendations — on the master detail page, a "Recommends" block linked to catalog products
• Purchase during booking — during online booking, a product is offered to add to cart via cross-sell component
• Pickup from barbershop — delivery service sale.delivery with "pickup" type, the client collects the order on their next visit

Payment — online via sale.paysystem or on delivery.

Men's style blog

A section on an infoblock with sections: hairstyles (trends, face shape selection), beard (care, styles), style (clothing, accessories). The article author is linked to the masters infoblock — this builds personal brand and internal linking. SEO-friendly URLs follow the pattern /blog/section/article-name/. XML sitemap is generated by the Bitrix SEO module.

Turnkey development deliverables

Total: from $2,500 (basic package). Upon completion, you receive a full package: commented source code, integration documentation, admin guide, access to all subsystems, and 3 months of warranty support.

What are typical development mistakes?

• Using a ready template without adapting for booking — losing up to 30% conversion.
• Direct AJAX requests to YCLIENTS with API key — data leak risk.
• Lack of composite cache for master pages — speed drop on mobile.
• Ignoring webhooks for back-sync — slots not updating.

Advantages of 1C-Bitrix over custom CMS

1C-Bitrix provides ready modules for catalogs, orders, and caching. According to documentation at dev.1c-bitrix.ru, tagged caching allows resetting only changed sections — this speeds up content updates without full invalidation. Unlike custom solutions, there is no need to design admin panel and access rights — everything is in the core. The content management system allows a manager to add services and products without a programmer.

Comparison with alternatives:

Our team specializes in 1C-Bitrix for over 5 years and has implemented 20+ projects for the service industry. Composite caching reduces page load times to 0.8 seconds — three times faster than custom CMS without cache. The barbershop website cost starts at $1,500 for a basic setup.

Technical foundation

• Responsiveness — mobile-first, booking on mobile takes 3 taps: master → service → time
• Composite cache — for service catalog, master pages, blog. Shop and schedule — no cache, AJAX
• Notifications — SMS reminder 2 hours before visit via messageservice, push if PWA wrapper is present

Common questions answered: Development time ranges from 30 to 60 working days, with the basic package taking 30 days. Supported booking systems include YCLIENTS, Dikidi, and custom HL-block schedules. A merch store can be added with SKU support. The schedule is kept up-to-date using caching with a TTL of 2-5 minutes and webhooks. The final delivery includes commented source code, integration documentation, administrator training, and 3 months of warranty support.

We'll evaluate your project in one day. Contact us for a consultation — we'll find the optimal solution for your barbershop's tasks. Get a commercial proposal with detailed stages and budget.

How to properly design infoblocks?

When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.

Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.

Why 1C-Bitrix outperforms most CMS for business

The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.

What highload blocks are and how they speed up the catalog

Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.

From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.

What integrations are critical for 1C-Bitrix stores

Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.

What's included in 1C-Bitrix website development

Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.

• Technical specification – user stories, infoblock diagrams, integration schemas.
• Source code in Git – with commit history, release tags, branching rules.
• Administrative documentation – description of custom components, deployment instructions, list of agents and events.
• Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
• Access to staging during development – test before production deployment.
• Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).

Our process and technologies

Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.

Process:

1. Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
2. Design – UI/UX with design system. Components are reusable.
3. Development – write components with custom templates in local/templates/. Business logic in local/modules/.
4. Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
5. Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.

Multilingual support and redesign

Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.

Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.

Guarantee and support

We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.