News·

What works today, and what we mean by finished

An inventory, nine days in. What runs on a real phone this morning, what is still on the bench, and the rule that decides when a thing is done.


Nine days after the first voice note, it is worth setting down exactly where this stands. Projects drift when nobody keeps a plain list of what actually works, and the drift usually shows up late, as a demonstration that only runs on the machine it was built on. So this is the list: what runs on a real phone this morning, what is still on the bench, and the rule we use to decide that something is done.

What we are building has not changed since the first day. One button on a phone, pressed and held while you say what happened, and behind it the ordinary back-office work of a small firm being quietly kept up to date. The machinery is written up elsewhere. This entry is about the state of it.

Working this morning

The recorder has had a rough week, which is rather the point of building it on our own jobs. A take dying somewhere between six and eleven minutes in, which turned out to be the stack on the audio thread rather than the memory everybody suspected. A “Recording” indicator that outlived the app that put it there, telling you it was listening when nothing was. A recovery scan that woke on launch, found the capture currently in progress, decided it was an orphan and helped itself. Every save failing outright because a scratch file from the export step was being counted as a recording.

All four are filed as issues, fixed, and covered by tests that would catch them coming back. All four were found the same way, by carrying the thing around and using it. Today you can swipe the app away in the middle of a sentence, or let iOS kill it under memory pressure, and the audio is still there and still playable when it comes back.

Past the recorder: a fast transcript appears on the phone within seconds, a better one replaces it from the server when there is a connection to reach it with, and the words are read for the things a business needs out of them. Whatever comes of that lands in a proposals inbox rather than in the world. Each proposal shows what it wants to do and what it read to decide that, and it sits there until a person taps yes or bins it.

Under all of it is a knowledge base made of plain markdown files with a page for each note, a link between notes where one depends on another, and a verified flag that stays off until somebody turns it on. At six in the morning, London time, a job on the server wakes, reads the calendar and those notes, and works out what is falling due this week. A wake it misses is caught by the next one rather than skipped. Behind the scenes there are admin screens for the captures, the receipts, the knowledge base, the proposals, the issue list, and an audit row for every action an agent has taken on our behalf.

Working today

Running on a real phone and a real server, this morning.

  • Recording that survives being backgrounded, force-quit or killed
  • Transcription on the phone, then again properly on the server
  • Actions pulled out of what you said
  • A proposals inbox where a person approves everything
  • A readable knowledge base, unverified until checked
  • The six o'clock duty sweep, proposing what is due
  • Admin views for captures, receipts, knowledge, proposals and the audit trail
On the bench

Specified, some of it half-built, none of it field-verified.

  • Recording from the side button with the app shut
  • A spoken sentence becoming a quote PDF and a draft email
  • Delegation: speak a task for somebody, and it gets chased
  • Listen mode, which shuts up and takes it all down
  • Connections into the CRM and the accounts package

What we expect it to do

The nearest of those is the side button. Press the physical button on the side of the phone with the screen off and the app closed, and be recording, because reaching into a pocket, waking a phone and finding an icon is three steps too many when somebody is mid-sentence in front of you. It is built and it works from a warm start; from a cold launch it currently refuses with a disk-space complaint that is simply wrong. That is the thing being fixed as this goes up.

After that comes the sentence that turns into paperwork. Say “write Bob an enquiry, two red plugs, two hundred quid of labour, I can do it in the next fortnight”, and get back a PDF and a draft email with the send button under your own thumb. No company registration number, no bank details, no form standing between you and a document worth sending. Delegation follows the same shape, one sentence turning into a memo somebody else receives and a loop that chases them when they do not answer.

Then there is listen mode, for the times the software should keep its mouth shut: a screen that says, in words, that it is listening and will not interrupt, while a long conversation runs its course. And the connectors, into the CRM and the accounts package, which are the point at which a mistake stops being an annoyance and starts being a wrong quote in somebody's inbox. That is exactly why the marked exam described in the trust piece is being built before them and not after.

A demonstration proves the code runs. A wet Tuesday in a plant room proves the product works.

What finished means

Everything here is verified twice. The first pass is ours: agents build the change on both surfaces, the phone app and the web client, and test it — unit tests, then the app driven in the simulator with screenshots read back, then the web client driven in a real browser against the live server. Only when that is green does anything get reported as built.

The second pass is a person with the phone in his pocket on a real job. He presses the button in a loft, in a van, at a trade counter, on a site with no signal, and he is the only one who closes an issue. Our commits reference the issue number and say plainly that they are awaiting field verification. Nothing is called finished until that second pass says so, and a few things on the working list above have been reopened by it.

Pass one

The agents, in the simulator

Unit tests, the real app driven on a simulator with the screenshots read back, the web client driven in a browser against the live server. Green here means built, and nothing stronger.

Pass two

A real phone, on a real job

In a loft, in a van, at the counter, out of signal. The simulator lies about audio: levels, routes and interruptions all behave differently there. Only this pass closes an issue.

That second pass exists because of one honest admission in our own technical plan: the simulator lies about audio. Levels are wrong, route changes do not happen, interruptions arrive politely and on time. A recorder that passes every test on a Mac has proved nothing at all about a plant room with a bad phone signal and a customer waiting.

Two rules sit above the whole list and settle any argument about scope. The recorder must never lose a take, so anything that risks capture outranks anything that improves it. And nothing sends or spends without a human yes, so a feature that would move money on its own does not get built in a form where it could.

We will keep this list current. When something moves from the right column to the left, it will be because somebody stood in a cold garage and proved it, and that is the entry worth writing.

Written on 27 July 2026, alongside two others: earning the right to press send, on how much the software is allowed to do on its own, and route to market, on the commercial side. The whole record is on the news page.


Read next