Skip to content
Hotstack

Order management for a bakery

Tiszafa Pékség

Tiszafa Pékség replaced a Google Form with an order manager: priced orders, a daily capacity ceiling, and one bake sheet the family opens in the morning.

Our role
Design, engineering, deployment, care
Period
2026
Platform
Web
One minute of the finished system: an order, a full day, the bake sheet. The interface is Hungarian, because the people who use it are. The recording carries seeded test data — the address, the phone number, the orders and the takings are not the bakery’s own.

We built an order manager for a family bakery that bakes to order. The customer orders from their phone, the bakery opens a single list in the morning, and the system will not take more orders than fit in the oven.

01

While the orders live in a spreadsheet

The bakery used a Google Form, and for a long time it worked. Then what a form cannot do caught up with them: one customer writes “two loaves”, the next writes “2 × half-brown”, and the price has to be added afterwards, in someone’s head, to every single line.

Anyone can fill in a form, too, so when something changes there is nobody to ring. And it cannot count: it will accept the twentieth order for a day that has room for twelve. All of it has to be understood at dawn, with flour on your hands, on a phone.

02

Structured orders, priced as they are placed

The customer picks a product, a quantity and a collection day rather than typing free text. The system does the arithmetic. Nothing is priced afterwards and no line is ambiguous.

The basket also states how long that day stays open. Someone who left it too late finds out then, not in the confirmation.

The bakery’s basket page with a collection day chosen: the line price, the total and the ordering cut-off on one screen.
The screenshots carry seeded test data, not the bakery’s actual orders and prices.

03

A day cannot be over-booked

A daily count per product, under one daily ceiling across all products — because the bottleneck is the oven and the hours in it, not the range. The bakery also sets which weekdays it bakes at all.

The limit is held by the database, inside a single locking transaction: if two people order the last loaf in the same second, only one of them gets it. The other is not shown an error but told which day to pick instead.

The basket page on a full day: the system explains that it cannot take an order for that day and offers to move it to another one.
The phone number is deliberately unreadable in this screenshot.

04

The bake sheet

One screen, ready for the morning: what to bake, how much of it, and how many orders sit behind it. Readable on a phone at arm’s length — because a screen slower than scrolling a spreadsheet does not survive in a kitchen.

The itemised order list lives on its own page, so the bake sheet holds nothing but what goes into the oven. One tap to the previous or the next day.

The “Mit süssünk” (what to bake) screen: the day’s products with quantities, and below them the order count and takings.
This is the one page the bakery opens in the morning.

05

The bakery sets the prices, not us

Products, photographs, prices, daily capacity, the ordering cut-off, the baking days: all of it is set in the admin. Nobody has to call a developer for any of it.

Customers can see their own orders and cancel them until the cut-off. After that they ring, and the bakery cancels on their behalf — one rule, not two.

06

Not only for bakeries

The frame is the same anywhere a day holds a finite amount and the customer collects in person: a patisserie, a butcher, a fishmonger, a florist, a daily lunch menu, a service appointment.

Three things decide whether this shape fits. Orders arrive today on a form, in a spreadsheet or in a chat thread. A day can only hold so much, and that limit is currently kept in someone’s head. And the customer pays in the shop, so online payment is not needed.

What we worked on

  • 01 Daily capacity per product and in total, enforced by the database
  • 02 More than 500 automated tests over the ordering and capacity logic
  • 03 Usable on a 390-pixel phone, on both the customer and the bakery side
  • 04 A Hungarian interface throughout, with every string in one place
  • 05 No card payment, on purpose: the customer pays on collection
  • 06 The source code belongs to the client

Building an application?

Tell us what you want. We write down what we would build and what it costs.

The website prices and the hourly rate are printed. Prices and hourly rate

Get in touch