Canteen management

Ghanaian day schools feed children at a canteen and take small cash sums every day, some paid ahead weekly or termly. It is the most cash-intensive money in the school and the least recorded: an exercise book, a cash tin, and a reconciliation done from memory. The founder put it plainly. Schools get cheated at the canteen. Collectors under-remit, kitchen staff under-serve and take stock home, and because nobody can say how much cash should exist at the end of a day, nobody can say how much is missing.

I built the first version as a payment log, and it is the clearest illustration of the problem because it encoded it. The collector sets an amount at the top of the screen, taps Daily or Weekly against each child, and publishes. The number is typed by a person, the class roster is the denominator, and a child who is absent is indistinguishable from a child who owes money.

Before any code, the thinking starts with brainstorming the problem space: who uses this, what can go wrong, what edge cases exist when money and attendance intersect. Every scenario that matters gets talked through, from a child arriving late to a guardian opting out mid-term to a collector who miscounts cash.

From there I build a canvas, a scratchpad for mapping out every screen and user flow before committing to code. Flows get rearranged and thrown away until the model holds.

Only once the canvas proves the logic does building in code start.

The founder came to the demo two and a half weeks in with a sixteen-screen prototype of his own and a different mental model, and he was right. Canteen is a metered utility, not a payment log. One engine answers a single question per child per day: is this a chargeable meal? It resolves through the calendar, then school policy, then participation, then attendance. Cadence stops deciding whether a meal is chargeable and only decides when it settles.

The load-bearing decision inside the rebuild is that eligibility and recording are separate acts. The system resolves what should happen today. A person records what actually happened. Nothing ever settles itself, so there is no auto-deduction from a wallet and an attendance mark never counts as a payment.

The second is two separate ledgers. Feeding money never blends with school fees, so a child can be square on lunch and behind on tuition and both read correctly, and lunch arrears roll into next term as their own bill rather than disappearing into the fees invoice.

I threw away two and a half weeks of work in one meeting. That was only affordable because of how it was built, which is the point of the method rather than an aside.

Frictionless adoption went deliberately. Collection is impossible until the attendance register is marked, which means the canteen now depends on a completely different part of the school system. The founder wanted exactly that: if the school's cash depends on attendance being marked, supervision arrives on its own. It also means a teacher who has not marked the register can stop the canteen collecting, so that screen had to do more than refuse. It names the blocker, says who clears it, and offers a one-tap route to fix it.

Hard guarantees went too, in favour of reason and proceed. A short handover closes with a named reason instead of blocking, which accepts that some gaps get explained and never chased, in exchange for days that always close.

And the refund button went entirely, once it was clear refunds are a rare manual accounting event rather than a product flow.

Cash integrity and the platform leverage built on top of it landed together, because they are input and output of the same thing. Policy layering across school, grade level and student, collection by class and by search, cash handover with counting and reconciliation, the feeding ledger with a shortage holding account, arrears with guardian reminders, the audit log, and wallets with mobile money top-ups and shared family pots.

The metered model is now the direction for canteen across the product, and two new roles, collector and canteen supervisor, entered the permission model because of it.

A pull request is raised with the full prototype and detailed documentation covering the entire feature. Every screen, every state, every edge case is documented so a developer picking it up has no ambiguity about what was built or why.

The docs spell out limitations, what the prototype fakes versus what comes from real endpoints, and where the boundaries are between frontend state and backend responsibility. Open questions are listed plainly rather than guessed at, and next steps are scoped so the backend team knows exactly what to build first.

This is the fullest expression of how I work. I ran the entire feature, product thinking and code, assisted daily by an agentic workflow, on a method I think of as design in code: the codebase is the design tool, a disposable branch is the artboard, and the output is a production ready prototype that communicates design intent to engineers.

On the playground branch, every surface carries a floating toolbar of state knobs, so any state, empty or partial or overdrawn or offline or six weeks into a term, is one click away without completing a flow. That is how I quickly iterate and accelerate my workflow and output. When a feature is ready, work is ported to a clean branch, productionized, and raised as a PR.

The one-day first version and the five-day rebuild are the proof. When building is that cheap, being overruled after a demo is a normal Tuesday, and the second version is better precisely because the first one existed to argue with.