The Rollecito

The Rollecito is the ordering platform behind a cinnamon-roll bakery in Los Angeles. It is not a storefront template — it runs the business: customers browse a per-location menu, configure and pay for an order, and follow it by tracking code, while the kitchen works the same orders through a live queue and staff manage the catalogue, promotions and locations from a separate back office.

A small bakery selling a made-to-order product loses money in two places at once. At the front, orders arrive over phone calls and direct messages, get transcribed by hand, and go wrong — a missing option, a misheard quantity, a customer who arrives before anything is baked. At the back, the kitchen has no queue: it has whichever note is currently on the counter.

The generic fix is a third-party ordering page. It solves the form and leaves everything else: no kitchen view, no per-branch menu, a commission on every order, and a catalogue that cannot express 'cream cheese frosting, add strawberries, no drizzle' without turning every combination into a separate product.

Ordering begins with a location, not a product. Choosing a branch scopes everything that follows: which items exist, which are available today, and where the order will be collected.

From there the customer configures an item through its option groups, adds it to a cart, and pays. Checkout does not require an account — guest ordering is a first-class path, because forcing a signup on a first-time customer buying a six-dollar pastry is how a bakery loses the sale.

After payment the customer gets a tracking code. The tracking screen is not a static receipt: it is subscribed to the same order events the kitchen produces, so the status moves as the kitchen works.

The catalogue is deliberately not a flat product list. Items belong to categories, carry option groups with their own option values, and are joined to locations, so the same item can exist in one branch and not another. Option groups can be cloned between items, because a bakery's toppings and frostings repeat across most of the menu and re-entering them by hand is how a catalogue drifts out of sync.

Orders reference the configured item and its selected options rather than a pre-computed product string, so the order total can be recalculated server-side at any point and a historical order still explains itself.

An order moves through five states — CREATED, PAID, PREPARING, READY, COMPLETED — and the transitions are enforced in the database rather than in application code. An order cannot skip a state or move backwards.

That placement is intentional. The same order is touched by the storefront, the webhook handler and the kitchen display, sometimes within the same second. If the rule lives in one of those callers it holds only for that caller; in the database it holds for all of them, including a future one that has not been written yet.

The kitchen view is a live first-in-first-out queue rather than a dashboard. Paid orders appear without a refresh, staff advance them through preparation and ready, and an order can be given priority or cancelled when reality requires it.

The same state change that redraws the kitchen queue also pushes to the customer's tracking screen. One event, two audiences — which is the reason the real-time layer exists at all.

Staff sign in through a separate authentication path from customers, and the back office is organised by role: menu and option management, locations, promotions, client records, order history, and revenue reporting.

The promotion engine has a preview step, so a discount rule can be evaluated against an order before it is published — a cheap safeguard against a promotion that turns out to be more generous than intended once it meets a real cart.

The backend ships as a Docker image to an AWS Lightsail Container Service; the storefront is built and hosted on AWS Amplify. Deployment is driven by GitHub Actions on merge to the production branch, behind a required manual approval — a deliberate brake on a system that takes real payments.

The API sits behind a security-header baseline and a strict cross-origin allowlist, with reCAPTCHA on the paths that would otherwise be attractive to automated abuse.

Revenue is direct: customers pay for their order through Stripe and the bakery keeps the transaction rather than a share of it after a marketplace commission. Owning the checkout also means owning the customer relationship, the catalogue and the pricing — including promotions, which are a first-class part of the system rather than something applied manually at the counter.

The same order row is written by three independent actors. The customer creates it and may retry. Stripe confirms it asynchronously, possibly delivering the same webhook more than once. The kitchen advances it while both of those are still in flight.

Any two of them can arrive in the wrong order or twice. A webhook that lands after a staff member has already started preparing must not push the order back to PAID; a duplicate delivery must not double-record a payment; a customer retrying checkout must not create a second live order for the same intent.

The answer was to stop treating correctness as something each caller is responsible for. Payment records are idempotent so a repeated webhook is a no-op, and the state machine is enforced by the database so an out-of-order write is rejected rather than merely unlikely. That is the reasoning behind the stored-procedure layer: it is the only place all three writers necessarily pass through.