Why a bakery's mobile app slows down during order peaks
Morning at a pastry shop is 40–60 minutes during which the bulk of the day's orders arrive: corporate sets, cakes for pickup, preorders for opening.
Taking orders at peak becomes a stress test: an app that responds in 300 ms during the day starts losing sessions and showing empty carts during that window.
The most expensive failure is a checkout interruption at the payment step. The cart lives in screen memory, and switching to a payment app or a brief network drop resets it: the customer returns to an empty screen and either leaves or rebuilds the order.
That's how duplicate orders appear — the pastry shop bakes two cakes instead of one, and the operator manually searches for matches by name and phone.
A separate story is the morning load on the store's back office.
If order creation goes as a synchronous request to the system the operator sees, then when its response is delayed, unfinished transactions pile up: the interface stops responding, and some orders "hang" in an intermediate status.
After that, orders are taken by phone and transferred into the back office manually — with delays and lost items.
We'll look at how to address this: where to store cart state so it survives a disconnection, how to protect against resubmission, and what to do with the order queue during the morning peak.
Effect of launch: order speed and repeat purchases
The effect of an app is measured not by the number of installs but by how many orders go through without a call to the store and how many guests return.
That's why we capture baseline metrics — checkout time, repeat purchase share, number of contacts with the seller — before launch and compare the first months of operation against them.
Checkout: minutes instead of a call
In the app, the guest sees the current display case assortment, chooses pickup or delivery, and pays in one step, so checkout time drops from several minutes of conversation to a couple of screens.
The address and order contents remain in the profile — a repeat order is assembled in two taps. Cake preordering is a separate scenario: a constructor for filling, layers, and decoration with date selection and a hint about how far in advance the store needs to be notified.
Repeat purchases and staff relief
Points for an order and a reminder at the hour when the guest usually gets coffee or pastries increase the repeat purchase share: the mailing goes out from the app, not through the sellers.
The load on store staff drops — the order arrives on a separate screen, readiness is marked with one tap, payment has already gone through online, and the cashier doesn't need to take the order by phone and enter it manually. The average pickup ticket grows through one-click upsell of a couple of items with the pastry.
Publication in Google Play and on the second platform plus funnel analytics show at which step guests drop off. After a few weeks, it's clear which reminders bring guests back and which pickup time is chosen more often.
Development formats: a single codebase, two native builds, a template
A bakery needs both platforms: some guests order on one, some on the other, and preordering and the loyalty card must work the same way.
The difference between the options is not what the guest sees but the amount of code the team maintains after release and the timeline for releasing the app.
| Option | When it fits | Limitations |
|---|---|---|
| Single codebase | Catalog, preorder, loyalty, notifications — the interface is the same on both platforms | Heavy graphics and system gestures suffer; requires an engineer who knows both platforms |
| Two native builds | Camera, payment, and notifications are needed at the limit of the system's capabilities | Double the work: two queues of edits, longer app release timelines |
| Ready-made app template | One store, a short season, quick order launch needed | Limited logic: custom loyalty scenarios and integration with the back-office system are built separately |
If the business is tied to a season
A ready-made app template covers launch in just a few weeks: the display case, cart, and notifications are already there; only the design and product mix change.
But custom mechanics — holiday sets, cake preordering, cumulative tiers — are built in before the season starts: adding logic in the middle of peak demand is risky.
If there are multiple locations
A chain benefits from a single codebase: one loyalty logic, one admin panel, support for both platforms by one team.
A native build per platform is chosen when you need to squeeze the maximum out of the device — for example, reliable payment on a weak connection in the store or instant receipt capture.
How implementation proceeds: from store analysis to build handover
Implementation starts not with mockups but with analyzing the store: how orders are taken now, where the queue builds up during the morning peak, who closes the shift, and what paperwork is used to reconcile revenue.
From this grows the order — payment — pickup data schema: it is what determines what the guest sees and what goes into the store's report.
The work proceeds in stages, each ending with a verifiable result:
- Store process analysis: the order path from display case and preorder to pickup, employee roles, bottlenecks during rush hour.
- Order — payment — pickup schema: order statuses, payment methods, linkage to shift and store so reports reconcile without manual matching.
- App development stages: a framework with catalog and cart, then the account area, order repeat, and readiness notifications.
- Testing on real orders: several shifts with real guests, including cancellations, additional payments, and out-of-stock items.
- Update release: publishing the build, the procedure for rolling out fixes, and the channel where error reports arrive.
- Handover and training of store staff: guides for the cashier and assembler, review of disputed shift scenarios.
Pre-release check
We test not against a list of buttons but against the order flow — a full day of store operation with a closed group of guests, including returns and orders for tomorrow.
An item that runs out by evening should honestly disappear from the catalog, and an already paid order should not break the shift.
Store staff training
The shift learns the app in one walkthrough: where to confirm readiness, how to process pickup by number, and what to do if payment doesn't match. The guide stays at the store, and we support the first days of operation until the order flow becomes steady.
What you receive: builds, schemas, access, regulations
The project closes not with a demo on a call but with the handover of a working environment. Everything needed for operation is recorded in the acceptance act — the customer checks each artifact and can launch the app or extend it with their own team.
- Builds for app stores — signed and ready for upload, plus a separate build for testing on employee phones.
- Source code handover: a full repository with change history; we set up access on the customer's account, not ours.
- App documentation: screens and order scenarios, data structure, third-party libraries and their licenses.
- Employee access policy: cashier, baker, manager, and owner roles with different rights to orders, stock, and discounts.
- Update regulations and escalation procedure: who receives a report during a failure and within what timeframe to expect a response.
Integration map
- Exchange schema with the back-office system: which events — new order, write-off, stock — go in which direction and how often they synchronize.
- Behavior during a connection loss: the order is not lost, goes into a queue and is resent, and the guest sees a clear status instead of an error.
Version release regulations
- Calendar: planned updates and unplanned fixes, who approves deployment.
- List of scenarios that must pass on the test environment before release.
- Rollback to the previous version if an update catches a problem in the production build.
Case study: a pastry chain doubled its order-taking speed
A pastry chain with twelve locations took preorders by phone and in chats: the operator manually transferred the cart contents into the back-office system.
During the morning peak and before holidays, checkout took up to four minutes, the queue at the cash register grew, and some orders were lost in chats. The cancellation rate due to store fault reached 12%, and almost every third guest called to check whether the order was ready.
We built an app with preordering for a specific pickup interval: the customer chooses the store, time, and cart contents, pays, and receives a readiness notification.
The order goes straight into the cashier workstation queue, so manual re-entry disappeared, and the status is visible to both the guest and the employee.
Exchange with the 1C back-office system keeps display case stock up to date and prevents ordering something the store won't be able to assemble in time.
After three months: checkout dropped from four minutes to forty seconds, the cancellation rate — from 12% to 2.5%, support requests to the store fell by three times, and calls asking "is the order ready" almost stopped.
One cashier shift became enough for the morning peak, without a backup operator. Repeat preorders grew to 34% — guests return for the same cake in the same interval.
What we did differently in the second stage
The first version sent orders into a common queue, and the kitchen during peak received dozens of items at once — cancellations returned.
In the second stage, we limited the number of orders per store per hour, introduced templates for frequent assemblies and an automatic confirmation deadline. If the store doesn't confirm an order on time, the interval closes, and the guest immediately sees an alternative time.
How does a single codebase differ from two native apps?
A single codebase is one source from which two app builds are assembled for iOS and Android; the native option is two independent projects in different languages. At the start, the difference is almost unnoticeable: both schemes produce a working product.
It shows up in operation, when regular updates, crash analysis, and new operating system releases begin.
The speed of releasing updates is determined by the number of release environments. An edit to the order scenario in a single codebase goes through one testing cycle and goes out to both platforms in one release.
With two native builds, the same edit is made twice, tested twice, and released on a separate schedule: while the second platform waits for release, users see different app behavior and send different support requests.
Access to device features is the flip side of this compromise. Camera, notifications, payment, geolocation, biometrics, and barcode scanning are covered by the common layer almost without loss.
It's more difficult with background work, external scanners and sensors, home screen widgets, and payments via the built-in chip: a native module is written for each platform, and the shared code provides the interface to it.
So the right question is not "can this be done" but what share of user scenarios lies outside the common layer.
The cost of supporting two branches grows nonlinearly: two update queues, double regression runs on the device fleet, and separate fixes for each app store's rules.
A single codebase maintains one work queue but concentrates risk — a failure in a common module goes to both platforms at once. Hence mandatory automated tests for critical paths and a phased release rollout.
The practical selection criterion is simple. If the product core is the display case, ordering, and the loyalty program, a single codebase wins: updates come out more often, and support isn't duplicated.
If the value is in rare equipment and deep work with peripherals, part of the logic still remains native, and the result is a hybrid with a common layer for business logic.
We calculate the share of code that is actually reused in both apps and propose a scheme based on that figure.
Integrations and payment: what is clarified before development starts
Before estimation, we fix four technical nodes: which back-office system the app integrates with, what payment methods we accept, how points and stamps are calculated, and what happens to the order between pickup and courier delivery. Until these points are described, the estimate remains a range, not a work plan.
We check not against documentation but on a test bench: a copy of the menu and inventory, test orders, a run of cancellations and returns.
This shows what discrepancies will surface in the first month of store operation — it's cheaper to close them before release than after launch.
Will the app see stock in real time?
If the back-office system provides data through an API, the display case updates with a delay of a few minutes — that's enough not to sell what's already sold.
When exchanging via uploads, we synchronize more often, and zero-stock items are by rule moved to "made to order" or hidden from a specific store's menu.
Which payment methods can actually be connected?
Online payment by card and QR code, payment on pickup, points and gift certificate redemption.
A refund for a canceled order goes through the same path as the payment — we build this into the status logic right away, otherwise cancellations will have to be closed manually at the cash register.
Where is the loyalty program stored?
It's more reliable to keep points and stamps in the store's back-office system rather than inside the app: then the cash register and display case see one balance, and iiko and similar solutions remain the single source of truth.
If accounting is done in spreadsheets, we move loyalty into a separate service with an operation log and protection against double redemption.
Let's discuss the task: what to send for estimation and a plan
To make the app development estimate substantive rather than a "range from and to," we need input on the bakery's processes.
We're not asking you to prepare a technical specification — it's enough to describe how orders live now and indicate what should move into the app. Based on this data, we assemble a work plan with stages, timelines, and scope of work.
- Description of the store and sales locations: format (bakery with seating, display case, kiosk), opening hours, average number of orders per shift, pickup and delivery — the logic of slots and kitchen load depends on this.
- Current order channels: phone, messengers, social networks, aggregators. It's important to understand which volume is where and where orders are lost — during peak hours, at confirmation, or at payment.
- Back-office system: cash register, inventory, recipes, loyalty program. We need to know whether menu and stock uploads exist and whether order statuses can be sent back to the back office.
- Menu and example items: categories, ingredients, allergens, size and packaging options, seasonal and preorder items.
- Employee roles: who takes the order, who assembles it, who confirms readiness and changes status — this is how we design access rights and notifications.
- Loyalty program: points, coupons, day-based discounts, personal offers. Determines what we transfer from current mechanics.
- Constraints and benchmarks: launch timelines, desired scope of the first stage, examples of apps you like or dislike.
Describe the task in free form — that will be enough for us to come back with an estimate and work plan.