Three systems.
All of them live.

The problem

A franchise group in Manchester supplies its sites from a central warehouse. Every week, sites order stock. The trouble is that some of those sites have a food safety certificate that expired in March, and some of them have an invoice that has been sitting unpaid for three weeks, and both of those are things head office only finds out about later, usually after the pallet has already gone out. Add the delivery day rules, the cutoff times, the weight limits on a van and the fact that different sites are on different pricing, and the person on the ordering desk is holding a set of rules in their head that nobody wrote down and everybody breaks.

What was built

An operations portal that connects head office, the warehouse, the franchise sites and outside inspectors, with seven roles that each see a different system. Ordering runs through the middle of it, and it is gated on compliance and on money: a site with an expired food safety certificate, or an invoice fourteen or more days unpaid, cannot place an order until head office lifts the block, and the override is logged with the name of whoever lifted it. Weight caps, delivery day rules and per-day cutoff windows are enforced in the same place, so the rules live in the software rather than in one person's memory.

Around that sit stock takes, the product catalogue, pricing tiers, invoicing and credit notes, compliance documents, scored audits, mystery shopping, a performance league table, a marketing calendar, a creative request pipeline, announcements, direct messaging, a document library and a reporting suite. Invoices, credit notes and delivery notes are generated as PDFs on the server and emailed as attachments the moment an order is approved, numbered sequentially with no gaps. Scheduled jobs chase unpaid invoices and pull each site's live Google review rating every day.

The stack, in plain language

It is a web application. Nothing to install, nothing to update, and it works on a laptop in the office and a phone in the warehouse. Everything lives in a Postgres database, so the ordering screen, the invoicing screen and the reporting suite are all looking at the same numbers rather than at three copies that disagree. The roughly 130 operations the front end can ask the server to perform are type-checked end to end, which means a change to the database schema breaks the build rather than breaking a page in production three weeks later. PDFs are rendered on the server, email goes out through a transactional provider, and the whole thing is deployed on Vercel.

For the technical reader: Next.js 16.1.6, React 19.2.3, tRPC 11.10, Prisma 5.22 on Supabase Postgres, NextAuth 5, Tailwind 4, @react-pdf/renderer, Resend, web push, Vercel.

The hardest part

The hardest part was not the ordering screen. It was deciding what happens when the software has to tell a paying site that it cannot have its stock. That rule is easy to write and hard to live with: block too eagerly and the warehouse gets a phone call and someone quietly turns the whole feature off, block too loosely and it is decoration. What made it survivable was the override. Head office can always let an order through, and the system records who did it and when, so the block becomes a question that gets answered rather than a wall that gets resented. Six months later the log is also the most useful report in the building, because it shows exactly which rules the business overrides every single time and therefore did not really mean.

The second hard part was access control, and it is the part that keeps us up. Seven roles, one of them an external inspector who should see scored audits and nothing else, one of them accounts who should see money and not compliance photos. Gating the routes is not enough on its own, because a route guard protects a page and not the data behind it. So permissions are enforced twice: once at the door, and again on every individual server operation, so that a request that somehow arrives without the right role gets refused at the point it asks for data rather than at the point it asks for a screen.

The problem

Leaflet distribution has an honesty problem, and everybody in it knows. You pay a distribution company by the thousand, they tell you the thousand went out, and you have no way of knowing whether it went through letterboxes or into a hedge. Take it in-house and you have swapped one unknown for another: your own staff are walking streets you cannot see, and at the end of the week you have a wage bill, a rough idea of the area covered and no answer to the only question that matters, which is whether doing it yourself is actually cheaper than paying someone else.

What was built

A tracker that staff open in the browser on their phone. It holds the screen awake for the length of the walk, records GPS continuously as the route is covered, and takes per-brand counts as the leaflets go out. The structure is Area, then Campaign, then Run, so a week's work rolls up into a campaign and a campaign rolls up into a territory. Admins get coverage maps per campaign, which is how the next push gets planned: you can see what was covered, so you can see what was not.

Underneath it are 1.79 million addresses imported from Ordnance Survey Open UPRN data, 1.32 million across Greater Manchester and 467,000 across Tyneside, which is what turns a walked line on a map into a house count. And there is a finance module that computes the cost per thousand leaflets from the actual duration of the actual walk, then sets it against an editable outsourcing benchmark. The system's entire purpose is to answer the question in the paragraph above, in a number, every week.

The stack, in plain language

A web app, opened in the phone's browser. Two things in it exist purely because of where it gets used. It asks the phone to keep the screen awake for the length of a run, because a screen that sleeps halfway down a street takes the tracking with it. And it subscribes to the phone's location for the whole walk rather than asking where you are every so often, so what comes back is a line that was actually walked rather than a scatter of points joined up afterwards. The maps are drawn as real vector maps rather than as pictures, so coverage shades street by street and stays sharp when you zoom. The three roles are separated at the database itself rather than in the interface, so a staff account cannot read another team's data even if a screen asked for it by mistake.

For the technical reader: Next.js, Supabase with row-level security, MapLibre, Tailwind 4, Wake Lock API, geolocation watchPosition.

The hardest part

The number this system produces is an argument. It says: stop paying the distribution company, because in-house works out cheaper. That is a real budget decision, and it means the cost per thousand has to be defensible to somebody who does not want to believe it. So it is computed from the actual duration of the actual walk rather than from an estimate or a target, and the outsourcing figure it is compared against is editable, so anyone doubting the conclusion can put the supplier's real rate in and watch what happens rather than being handed a number and asked to trust it.

Which pushes the difficulty back down the chain onto the phone in someone's pocket. A route is walked through terraced streets with poor signal, in the rain, by someone whose job is delivering leaflets and not operating software. Every design decision in the field app follows from that: the fewer taps a run needs, the more likely the data underneath the finance report is real. A tracker that is annoying to use gets used carelessly, and carelessly recorded runs produce a confident cost per thousand that is quietly wrong, which is worse than having no number at all.

The problem

This one is ours and it is not solving a business problem, it is a product. Six binary football questions a day, called before kick-off, settled overnight. No money goes in and none comes out. The interesting problem is not the game, it is that a daily game has to actually be daily: the card has to be built before anyone wakes up, the results have to be settled before anyone checks, and it has to happen on a Tuesday in February when nobody is looking at it. A daily product that misses a day is not a product.

What was built

Seven scheduled jobs running the daily cycle without anyone touching it. Fixtures come in, the day's card is built, the morning email goes out, results are settled overnight, and a late pass sweeps up anything that was not resolved the first time. On top of that sit XP, streaks, achievements and leaderboards.

The questions are generated from live bookmaker odds rather than written by hand, with the bookmaker's margin stripped out first, and they are then selected for genuine balance. A question that is obviously going to be yes is not a call, it is a formality, and a game made of formalities is boring by the second day.

The stack, in plain language

A web app with a database behind it and a scheduler in front of it. The seven jobs run on a timer on the hosting platform rather than on a machine sitting under a desk, so there is nothing to reboot and nothing that stops when a laptop closes. Odds arrive from a football data provider, email goes out through a transactional provider, and the whole daily cycle is unattended by design.

For the technical reader: Next.js 16, React 19, Supabase, Resend, API-Football, Vercel.

The hardest part

The odds. A bookmaker's prices never add up to 100%, and the excess is how they make a living. Take their numbers at face value and every question you generate looks more likely than it really is, so the first job is stripping that margin out to get back to something like a true implied probability. Only then can you ask the question that matters, which is whether a call is genuinely close to a coin flip. Six questions where the answer is obvious is not a game. Six that could go either way is, and telling those apart is arithmetic, not editorial judgement, which is the only reason it can be done fresh every morning without a human picking them.

Settlement is the other half, and it is less clever and more unforgiving. Every night the system has to decide, for every call every player made, whether they were right, then award the XP, extend or break the streak, check the achievements and rebuild the leaderboards, all with nobody watching. The failure that matters is not a crash, because a crash is loud. It is a match that finished late, or a result that arrived after the settle job had already run, which would leave a player looking at a call that never resolved. That is what the late pass is for: a second sweep hours later that picks up whatever the first one could not see yet.