01
First call
Thirty minutes. You say what is not working and what you are trying to reach. We say honestly whether we are the right people — sometimes the answer is no, and it is cheaper to hear it now.
Problems / 005
What
we fix.
The registry describes each system by what it may read, write and refuse. This page says the same things in the words of the person who owns the problem — and every line on it points back at an entry that runs.
7 problems, backed by 12 of the 12 registry entries. 10 of those run in production; the rest are labelled below as what they are. Nothing here describes a system that was not read in source.
01
Receipts and invoices typed by hand
A donation receipt or a sales invoice is a document you are legally answerable for, produced by someone re-keying what another system already knows. It is slow, and one duplicate is a correction you have to explain.
The donation or the order arrives; the receipt or invoice is issued from it and recorded. A person is pulled in only for the ones that genuinely need a decision.
It will not: Issue the same document twice when the trigger arrives twice — or act at all without the exact permission to do so.
02
Reading paperwork into your system
Expense receipts arrive as photos and PDFs, and someone types the fields out. That person is the bottleneck, and the typing is the dullest part of their job.
The document is read and returned as structured fields for review. What is genuinely unclear comes back empty rather than guessed.
It will not: Write anything on its own. It proposes; a person accepts.
03
Running second-hand stock without a spreadsheet
Consignment deadlines tracked by hand, and every incoming item priced from memory. Both go wrong quietly, and the depositor is the one who notices.
Depositors are told where their consignment stands at fixed points, automatically. Each incoming item gets a starting price from what comparable items actually sold for, and a person sets the final one.
It will not: Suggest a price when the evidence is too thin. It returns nothing rather than a number that looks confident.
04
Orders fulfilled from an operator's file
A batch of orders arrives as an upload, and fulfilling them means a person clicking through each one — or a script that touches live orders with no rehearsal.
The file is verified end to end in a dry run first. Only a run explicitly marked live touches an order.
It will not: Change anything unless the caller has said, in so many words, that this run is live.
05
Live systems that need babysitting
Stale holds sit in a booking system until someone clears them. Updates on a live site are applied and then hoped about. Both are small chores that quietly become someone's Monday.
Stale records expire themselves on a schedule. Site updates are applied, checked from the outside in a real browser, and reversed automatically when the site comes back worse.
It will not: Keep an update whose result is anything short of a clean pass — and it backs up before it touches anything.
06
Publishing at volume without publishing mistakes
Lessons with figures in them, narrated video, brand imagery from a model: each is cheap to produce and expensive to retract. The risk is not that the machine is slow. It is that it ships something wrong, at speed.
Every figure an author declares is recomputed before a lesson can build. Narration is checked before a voice is made from it. Image generation stops at a human gate wherever a wrong result would otherwise ship.
It will not: Build a lesson whose arithmetic does not hold, or voice a line that carries a known fault.
07
Inbound messages nobody has time to sort
A shared inbox where every message is read once to decide what it is, and a second time by the person who handles it.
Each message is labelled by intent. What can be classified with confidence is resolved; the rest is queued for a person, in a queue sized against how much reviewing they can actually do.
It will not: Resolve anything below its confidence threshold.
How it starts
Three steps before anything is built.
02
Look at the real thing
Your tools, your data, the way work actually reaches the person who does it. Most of the important problems are visible here, and often not the one you called about.
03
Scope and price
One document: what will be built, what it will be allowed to do, what it costs. Fixed where it can be fixed. Where something is genuinely unknowable up front, we say so instead of padding.
Not on the list? The list is what has been built, not the limit of what can be. Start with the operating problem; the shape of the system follows from it.