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"
| Field | Type | Example Values |
|---|---|---|
| UF_TYPE | List | base / filling / cream / decor |
| UF_NAME | String | Vanilla sponge, Chocolate ganache, Fondant |
| UF_PRICE_PER_KG | Number | Price per kg (for base, filling, cream) |
| UF_PRICE_FIXED | Number | Fixed price (for decor) |
| UF_IMAGE | File | Preview in interface |
| UF_LAYER_IMAGE | File | Layer image for visualization (transparent background) |
| UF_COMPATIBLE | String | JSON of compatible IDs — not all creams suit all bases |
| UF_ALLERGENS | List (multiple) | Allergens of the component |
HL-block "Shapes and Sizes"
| Field | Type | Example |
|---|---|---|
| UF_SHAPE | List | round / square / heart |
| UF_TIERS | Integer | Tiers: 1, 2, 3 |
| UF_WEIGHT_MIN | Number | Minimum weight in kg |
| UF_WEIGHT_MAX | Number | Maximum weight |
| UF_WEIGHT_STEP | Number | Step (0.5 kg) |
| UF_MULTIPLIER | Number | Coefficient: two-tier = 1.3 |
HL-block "Cake Orders"
| Field | Type | Purpose |
|---|---|---|
| UF_CONFIG_JSON | Text | Full configuration in JSON |
| UF_WEIGHT | Number | Final weight |
| UF_PRICE | Number | Calculated price |
| UF_ORDER_ID | Integer | Link to sale order |
| UF_DESIRED_DATE | Date | Desired readiness date |
| UF_STATUS | List | new / confirmed / in_production / ready / delivered |
| UF_COMMENT | Text | Inscription on cake, wishes |
Step-by-Step Interface
-
Shape and Size. Choose shape (round, square, heart), number of tiers, weight via slider. For multi-tier, automatic distribution: bottom tier 60%, top 40%.
-
Base. Sponge layers for each tier separately. Cards with photo, name, and allergens. Selecting updates the visualization — layer changes texture.
-
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. -
Cream. Similar to filling, with compatibility check.
-
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.
-
Total. Visualization (layered rendering of
UF_LAYER_IMAGEvia CSSposition: absolute), full composition, combined allergens of all components, nutritional info, price.
Price Calculation Formula
Price = (Σ price_per_kg × weight) × tier_coefficient + Σ decor + urgency_markup Urgency markup: less than 48 hours until readiness — +30%. Less than 24 hours — order unavailable (minimum production time). Validation of UF_DESIRED_DATE on server considering bakery's days off.
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
| Stage | What's Done | Duration |
|---|---|---|
| Prototype | Wireframes of configurator, information block structure | 3–5 days |
| Design | UI of configurator, catalog, product card, mobile version | 5–7 days |
| Markup | Responsive layout, configurator animations | 5–7 days |
| Backend | HL-blocks, calculation controllers, sale integration, POS | 7–10 days |
| Content | Catalog filling, photography | 3–5 days |
| Testing | Configurator calculations, load, mobile | 3–4 days |
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.