The second client in a trade starts where the first one finished.

The problem it kills

A small independent business in a trade — a restaurant, in this case — is software-rich and budget-poor. The work is not hard. The problem is that it gets re-derived from scratch every time, and re-derived wrong in the same four places: the costing arithmetic skips a step, the owner is asked on day one for data they have never written down, the customer analytics measure people who made an account rather than people who buy, and the question that decides the whole product shape gets asked in month two.

So the deliverable is doctrine, not a package. There is no repository to clone. What travels is the order to build in, the shape of the data, the questions to ask before writing code, and about two dozen positions each earned by a specific failure — including the ones we got wrong ourselves.

What transfers is the order to build in, not the code.

The arithmetic almost everybody skips

Purchase unit, to base unit, to yield, to portion. Four steps, and the third is the one that gets dropped — because it is invisible when it is missing. A case of tomatoes at $31.75 holding 400 ounces is 7.9 cents an ounce on paper. After an 88% trim it is 9 cents. A four-ounce portion costs 36.1 cents, not 31.8.

That is 13% understated on every plate using that ingredient, forever, with no screen anywhere in the system able to reveal the error — because the number is arithmetically consistent, just wrong. Across produce the gap runs 8 to 30%. A menu priced off the version without yield is a menu that quietly loses money on its best-selling item.

Counting the customers who never sign in

Almost nobody creates an account to order a pizza. They tap a card and leave. Every loyalty product that opens with "get them to register" is answering a question the customers already declined, and a dashboard built on registered users is measuring its own signup flow rather than the business.

So identity starts at the card — not the number, which never enters the system at all, but the processor’s own stable fingerprint plus the brand and last four digits a human needs to recognise a row. A card is never allowed to create a customer record: building a named profile of somebody who never gave a name is a different product, and not one we were asked to build. And because these people have no email and no phone by design, every screen that offers them something says plainly that the shop can recognise them and cannot contact them.

The card number never enters the system. The recognition does.

What runs before the real data arrives

The honest answer to "we do not have recipes yet" cannot be "then we wait." So the system runs on modelled sales and proposed portions — and every one of them is labelled in the data rather than in a caption, which means no screen has to be told and no caveat has to be remembered. The day one real day of sales lands, the warning weakens by itself.

The rule underneath it: an estimated quantity multiplied by a real price produces a figure indistinguishable from a fact. So the label travels — from the row, through the computation, into the margin advice two screens downstream, where it would otherwise quietly become a quote. And where a price is missing entirely the plate costs nothing at all rather than the sum of the parts we happen to know.