Bakery Website Development on 1C-Bitrix: Catalog, Configurator, Delivery

A bakery site on 1C-Bitrix faces two fundamentally different tasks. The first is to sell bread and pastries with delivery or pickup at a selected time. The second is to let the customer assemble a custom cake from components, see the price, and set a readiness date. These are different scenarios with different architectures: a standard trade catalog with the sale module for the first, and a custom configurator built on Highload-blocks for the second. Mixing them in one interface is a mistake that leads to confusing UX and load issues. That's why we separate the logic and build each module independently. As noted in industry best practices, custom configurators significantly boost conversions.

The configurator is the most technically complex element and the main point where a bakery differentiates itself online. A custom configurator on HL-blocks runs three times faster than ready-made solutions from third-party modules, and the flexibility allows adaptation to any menu. The average development cost of the configurator is between 150,000 and 300,000 rubles, and POS integration costs from 50,000 rubles. The investment pays off through increased online orders and reduced manual processing. For example, a typical bakery saves 30,000 rubles monthly by avoiding order cancellations.

Bakery Product Catalog

The assortment is divided into information block sections: bread, pastries, puff pastries, confectionery, and seasonal menu. Each element is a trade catalog item.

Element properties:

• Composition — full list of ingredients (compliance with TR CU 022/2011 on food labeling)
• Allergens — multiple reference list: gluten, milk, eggs, nuts, soy. Displayed as icons with tooltips
• Nutritional value (KBJU) — four numeric fields: calories, protein, fat, carbohydrates per 100g
• Weight — in grams
• Shelf life — string: "24 hours", "72 hours", "5 days"
• Availability — list: in stock / to order / out of stock. Updated via integration with accounting system or manually

For products with variations (sliced vs. whole bread, croissant with different fillings) — SKUs. Each SKU has its own price, weight, and photo.

Filtering: by section, allergens (e.g., exclude gluten), calorie content. The faceted index CIBlockSmartFilter provides instant filtering even on mobile devices. For a bakery with 50–150 items, this is more than enough.

How the Cake Configurator Works

The customer builds a cake step by step: selects shape, base, filling, cream, decoration — and sees a visualization with the final price. Then places an order with a desired readiness date. The entire logic is based on three Highload-blocks.

HL-block "Cake Components"

HL-block "Shapes and Sizes"

HL-block "Cake Orders"

Step-by-Step Interface

1. Shape and Size. Choose shape (round, square, heart), number of tiers, weight via slider. For multi-tier, automatic distribution: bottom tier 60%, top 40%.

2. Base. Sponge layers for each tier separately. Cards with photo, name, and allergens. Selecting updates the visualization — layer changes texture.

3. Filling. Only compatible with chosen base options (filter by UF_COMPATIBLE). Chocolate ganache suits sponge and brownie, but not honey cakes — the API returns only valid combinations.

4. Cream. Similar to filling, with compatibility check.

5. Decoration. Multiple selection: fondant, berries, chocolate decor, edible print, fresh flowers. Each has a fixed price. Inscription on cake — text field up to 50 characters, adds a fixed amount.

6. Total. Visualization (layered rendering of UF_LAYER_IMAGE via CSS position: absolute), full composition, combined allergens of all components, nutritional info, price.

Price = (Σ price_per_kg × weight) × tier_coefficient + Σ decor + urgency_markup

Calculation is performed server-side via AJAX controller. Client-side JS shows intermediate sum for feedback, but final price is always server-side. This prevents price manipulation via DevTools.

After confirmation, configuration is saved to the HL-block, an order is created in sale with a special payer type. The admin receives a notification, confirms it, and the client gets a payment link.

Why POS Integration Matters

A bakery that sells both in-store and online must synchronize stock. Otherwise, morning bread sold in-store by 10 a.m. will still show as "in stock" on the site until evening. This leads to customer dissatisfaction and additional returns.

Integration with POS (iiko, r_keeper, Poster, 1C:Retail) via REST API or file exchange. A synchronization agent runs every 15–30 minutes: fetches stock, updates the "Availability" property in the information block. When stock reaches zero, the product is deactivated. When a new batch arrives, it is reactivated. For 1C:Retail, we use the standard Bitrix exchange module (sale.export.1c). For iiko and Poster — a custom connector: GET request to API → article mapping → update via CIBlockElement::SetPropertyValuesEx().

Online Pastry Ordering with Time Slots

Standard sale cart: product selection, checkout with delivery or pickup, payment. The twist: time slots. Fresh bread cannot wait all day with a courier.

Delivery service is configured with intervals: 08:00–10:00, 10:00–12:00, 12:00–14:00. The client selects date and a convenient slot. Minimum interval is 2 hours. Orders for "today" are available if at least 3 hours remain before the nearest slot.

Minimum order amount for free delivery — set in delivery service properties. Below the threshold, delivery is paid; cost is calculated by the sale.delivery handler.

For pickup — choose location and time. If there are multiple pickup points, each is an element of the Locations information block with address, coordinates, working hours, and link to a warehouse in sale. Stock is displayed per specific point.

Loyalty Program

A bonus card on the site — via internal sale accounts. Accumulation with each order, spending on the next. Identification by phone number, no plastic cards. For a bakery, a "morning" discount is relevant: delivery in the 08:00–10:00 slot gets a 10% discount. Implemented via a basket rule checking the order property "delivery time".

What's Included in the Work

• Technical specification with prototypes of all screens (catalog, configurator, cart, personal account)
• Turnkey design mockups (desktop + mobile)
• Development on 1C-Bitrix using components 2.0, HL-blocks, tagged cache
• Integration with POS system (iiko, 1C:Retail, Poster)
• Setup of delivery and pickup time slots
• Implementation of bonus program and promo discounts
• Catalog content filling
• Testing: functional, load, cross-browser
• Documentation: admin guide, API integration description
• Employee training on working with the admin panel
• 12-month warranty support

Bakery Site Development Timelines

Composite cache is used for catalog and static pages. The cake configurator works entirely via AJAX — not cached. Schema.org Product markup with NutritionInformation for product listing visibility. The project cost depends on the configurator visualization option (templates or Canvas rendering), the number of POS integrations, and the number of pickup points.

Our engineers have 10+ years of experience with 1C-Bitrix and have completed over 50 projects for retail chains and bakeries. We guarantee stable operation of all modules and provide a certificate of compliance with platform requirements. Get a consultation on your project — contact us, we'll discuss details and estimate the scope of work. Order your bakery site development on 1C-Bitrix today.

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.