A whole bakery, designed as one system, from the flour order to the books.
I built a website for a bakery and pizzeria, and a website only ever touches the front counter. Behind it there is purchasing, a production kitchen that bakes overnight, two stores, a wholesale route, custom cakes, a delivery van and an accountant, and in most places that is five programs and a clipboard. So I sat down and designed the whole thing as one system, for a bakery that does not exist. Nothing here runs. The screens are drawings with made-up numbers. What is real is the design underneath them, and the numbers on every screen agree with every other screen because the design says they have to.
Buying it
Nine suppliers, and each one behaves differently. Some sell by the case and bill by the pound. One takes three weeks. One prints your boxes and wants six. The system suggests what to order and when, works out the day the shelf runs dry, and keeps a record of whether each supplier shows up when they said they would. A person still decides and sends the order.
Knowing what you have
Nobody types in a stock count. Every movement is a line in one ledger: received, baked, sent to a store, sold, dropped on the floor. What is on hand is that ledger added up. So when a number looks wrong, you can read how it got that way, line by line, with a name and a reason on each.
Deciding what to bake
Orders close at one o'clock. At two the plan for tomorrow locks: what each store needs for that day of the week, plus wholesale, plus the custom cakes due, minus what will be left over tonight and still good. It rounds up to whole batches and checks that the ingredients are on the shelf before anyone turns on a mixer.
Baking it
A batch says what was planned, what came out, and what it really cost. It used the oldest lot of each ingredient at the price that lot was bought for, so the cost of a cookie traces back to a specific delivery from a specific supplier. Four cookies broke coming off a pan. The other 236 each cost a little more because of it.
Selling it at the counter
A cookie comes out of the case, so selling one takes one out of stock. A pizza does not exist until somebody orders it, so selling one takes out a dough ball, sauce, cheese and toppings by the portion, and a box only if it is leaving the building. Extra cheese is a second portion. No cheese takes one away. The register also knows a cookie to go is not taxed and a pizza is.
Selling it by the case
Restaurants, cafes, grocers and a college get standing orders: the same thing every Tuesday until they say otherwise. They can change tomorrow's order until one o'clock. The van goes out at five. The invoice is written at the door, for what was actually delivered, which is not always what was ordered.
The cake somebody ordered two weeks ago
A custom cake is money now and a sale later. The deposit is money the bakery owes someone a cake for, and it stays that way until the cake is picked up. The order carries its own rules: what can change and until when, what happens to the deposit if it is cancelled, and whether the cake department has room that day.
Finding out if it made money
One screen follows a product all the way through: recipe, cost, stock, production, sales, what it keeps. Another lines up every product and shows which ones cost more than their recipe says they should. The chocolate supplier raised prices on the first of the month. Everything with chocolate in it now costs seven percent more, and the prices have not moved.
Telling the accountant
The accounting software does not need four hundred cookie sales. It needs one day's totals for each location. So that is all that crosses over. Each entry is labeled so it can never post twice. If the accounting service is down, the entries wait and try again, and nothing at a register notices.
And what the owner looks at
One page for the morning coffee. Sales so far, and then the handful of things worth an owner's attention, each in a plain sentence, each one a link to the screen that explains it.
One ledger that is never edited
Stock is not a number somebody keeps up to date. It is a history that gets added up. A mistake is fixed by a second line that reverses the first and says why, so the past always reads the way it happened.
One program, one database
No microservices and no message bus. Eighteen parts with hard edges between them: every record has exactly one owner, and only the owner writes to it. Everything else asks.
It buys what it should not build
Card payments, the accounting package, payroll and tax rates stay outside, each behind a plain contract. If any of them goes down, the stores keep selling and the messages wait.
It is a design, not software. Seven documents: the business, its processes, the records it keeps, what gets written down when, who owns what, where it meets outside services, and a stress test. Then these fourteen screens, drawn from the documents.
The stress test ran twenty three bad days against the design. The supplier is out of flour. Somebody receives a thousand pounds instead of a hundred and nobody notices for two days. A cake is cancelled the day before. The internet goes down. Twelve held, ten found a gap, and one broke it. The gaps were fixed in the design. The one that broke it is the internet going down, and the honest answer there is paper.
What does it look like behind your counter? How many programs is it, and which two do you wish talked to each other?