Concept, brand, product design, build
An AI agent for UK sole-trader tradespeople. A voice note, a photo, a rough message goes in; a priced, customer-ready quote comes back, in WhatsApp, before they've packed the van. I built the whole thing: the concept, the brand, the website, the product and its architecture.
Concept, brand, product design, build
WhatsApp-native agent + hosted artefacts
State machine · tool-rails · append-only event log
Ran live · two pilots · pivoted
There is more test code than source code, which is the number I would defend hardest. A system this carefully built, used by two people, is a sequencing problem rather than an engineering one. That is the whole lesson of this project and the rest of this page works towards it.
A UK sole trader quotes from a photo of a wall, a voice note in the van, a half-remembered chat at the door. Then the evening goes on writing it up. And the job goes to whoever replies first, not whoever is best.
The failure moment is specific: turning mess into a priced, customer-ready quote while still on site. Nothing cheap rehearses that moment. That is the whole product.


The tools are split into two halves: prepare and apply. The model can only prepare a change, which puts it on hold and asks the tradesperson to confirm it in their own words. The change is only actually applied once the tradesperson's reply has been checked and accepted as a genuine confirmation, and the model has no way to make that final step happen itself. Nothing is ever overwritten: every change is saved as a new entry, with the previous one simply marked as no longer current, and the event log is locked down so that any attempt to edit or delete a past entry is automatically blocked.
Gate two is my favourite thing in the codebase, because it exists as the result of being caught. An audit found that any part of the system could simply mark a piece of information as "confirmed" without ever checking it against where that information actually came from, which meant the gate did nothing to catch data the AI had merely guessed rather than verified. The fix closed that backdoor: now something can only be marked confirmed by tracing it back to its real source, never by just declaring it so. The comment recording that fix is still in the file, with the date.
The near miss that justifies keeping the arithmetic in code at all, never the model: an early version silently dropped two labourers from a quote entirely. My own log at the time: "it's missing my two mates, labouring for £180 a day for 5 days." £1,800 of real labour, gone, caught before it reached a customer.
Per turn. Picks Haiku over Sonnet only when the state is safe, the intent is read-only and every requested tool is a read tool. Anything that could change a fact forces the larger model.
Daily, batched, half price. Quiet hours 21:00 to 08:00, one message a day, only for users active in the last week. Nudges go to the tradesperson, never to their customer.
Watches each turn for patterns, consolidates weekly with no model call at all.
The design documents call for a Head Reviewer Agent: a second model that checks the first one's proposals and approves them. I never built it. Instead, I broke the supervisor down into parts that cannot drift: fixed cut-off numbers that never shift on their own, a rules table matching each state to what happens next, an exact-match check that catches duplicate entries, and a human review queue at the end. A second model checking the first isn't a safety feature. It's the same mistake happening twice, and it costs more.
Anyone can call the same model I do. A sole trader's voice note says "chuck in some T&E and a couple of double sockets." A generic assistant hears a sentence and writes something plausible and useless; this one already knows the trade.
What a fresh competitor cannot buy on day one is the layer above it. Every approval and every edit is a signal, weighted into that user's profile, so the baseline improves and the edits shrink. The design bet was that a competitor starting from scratch could not shortcut six months of accumulated signal, a bet the project never ran long enough to test. The ladder below is how one correction was meant to become product-wide confidence without ever skipping the human at the top.
Signal comes from the highest-quality source available: what the tradesperson changed in a draft before sending it, plus their reactions, voice and replies. Each time the same pattern shows up again, the system's confidence in it grows by a fixed tenth of a point, though it levels off at a ceiling rather than climbing forever. Repeats are recognised automatically within a seven-day window, so the same pattern can never be raised twice.
The rung that matters is the third one: the system asks the tradesperson to confirm or dismiss what it thinks it has learned, as a first-class tool call. And the two brakes at the bottom are what I would want a reviewer to notice: regulatory patterns are skipped outright, and nothing anywhere in this ladder writes product configuration without a person.
Eleven levels of difficulty, from a preflight check to a messy, one-input home run, each scored out of ten. Average score: 9.0. The top level is deliberately kept below a perfect ten, because it still needs testing across a wider range of cases, particularly keeping track of who said what and handling unclear input.
A hundred-point taste gate, kept separate from correctness. Currently 95. A quote can be functionally perfect and still fail if a tradesperson would not be proud to forward it.
This category covers the failures that matter most: one customer's data leaking through to another, an attacker slipping in hidden instructions to hijack the AI, the AI sending something to a customer without a human approving it first, or the AI making up a price that is not real. 100% or it does not ship. Every other test category only needs to pass 70 to 80 times out of 100. This one allows no failures at all.
The most honest line in the whole project is inside the luxury rubric: a hundred out of a hundred still requires a human to look at a freshly generated PDF after deploy, because automated geometry cannot judge whether something looks premium. Taste is the part that does not automate, and writing that into the rubric is more useful than pretending the number is complete.
The row that matters is the reviewer queue. If a day rate creeps up gradually, say from £65 to £75, and three separate corrections all agree on the new figure, the system is 82% confident and accepts the change on its own. But if a rate jumps in one go, say from £55 to £90, that is a 63% change in a single step, too big for the system to trust by itself, so it holds the change back for a person to check. Confidence is tracked per field, so the system knows it is sure about VAT status and unsure about brand voice, and behaves differently in each case. The design bet underneath it, in my own words at the time: "better to estimate and be corrected than all blank."
There was a fourth check, meant to stop the first three being read too generously. It was a set of readiness checks for the pilot, run under one rule: "a green ladder is not a green pilot." This score was worked out automatically from whether each step had actually been confirmed working, never set by hand, and it showed what the 9.0 average was hiding: the payment process was only confirmed working in two of the six places it needed to work, the activation process in just one of four, and the invoicing process in just one of four.
Horizon planning beyond two weeks. Strategic forks and north-star deltas. Writes no production code, and is meant to see further than the rest of the system can.
Authors briefs, monitors pull requests, keeps the audit rail. The operator seat.
Hammer does the work itself, making changes directly to the code and the documentation. It is explicitly barred from delegating tasks to other sessions, so it can never quietly turn into a second Dispatch.
Workflow hygiene needed attention too: several working copies of the codebase running in parallel, old lines of development left open long after they were finished, and documentation that had gone stale and drifted out of step with what the product actually did. One clean-up pass alone brought the number of these open lines of development down from 326 to 64.
User research and dogfooding. Live sessions, persona keeper, triage of findings.
Three AI agents do the work: a builder, an auditor and a janitor, each with its own working copy of the code that it keeps between runs rather than starting from scratch each time. The auditor is required to push back with counter-recommendations, not simply agree with the builder.
The standing rule for cross-model review was "Agreeing is a failed review." The rule that makes it usable rather than noisy is a second one: every finding must cite a verbatim file and line before it counts. A finding without a code anchor is not a finding. Every finding is triaged as confirmed, partly debunked or needs-verify before it counts, which routinely reclassifies some as false positives, and occasionally shows the bug is worse than the discoverer claimed.




There was a rule while building it: no dead buttons. If a button wasn't wired up yet, clicking it opened a pop-up that said so plainly, along with a short on-screen message reading "this will be handled in WhatsApp during the pilot". I would rather show an honest placeholder than a button that silently does nothing.
What "never fully wired up" actually means is precise and slightly painful. The back end shipped: the sign-in-protected sections for jobs, approvals, previews and payments (Stripe Connect) were built and live, with secure logins that expired and only ever showed people what they were allowed to see. The app meant to use it did not. In the finished, live version of the code there is no way for the dashboard to log someone in on its own, so the only way in is to paste a long security code into a text box by hand. The login that would have closed that gap, a one-click email link, was built. It is just sitting in an unfinished version of the code that never made it into the live one. The back end shipped and the front door did not.
There was no native mobile app, and I want to be exact about that because it would be easy to imply otherwise. There is a mobile web surface, a phone-frame chat view and a bottom tab bar under a 720px breakpoint, plus a set of mobile invoice explorations rendered in an iOS frame. That is a responsive app, not an App Store one.
Generate a tradesman's whole visual identity from his trade and trading name: palette, three text-free marks, a few pence of model calls. Sixteen UK trades mapped, five test brands rendered, a complete implementation spec written. The flags were never turned on.
The full agentic loop with 25 registered tools, shadow-run against the live state machine for comparison. It beat the control on memory-relevant turns at a third of the cost, and it never served a single real user.
The hundred-times version: the AI that sets up and runs a trade business, not just its quotes. Written up in full with five named unvalidated assumptions and an explicit gate for un-parking it.
Plumber, electrician, tiler, roofer, plasterer. Each one a vocabulary pack on the same engine. Depth was only ever built for painter and carpenter.
Programmatic SEO where each trade config becomes a page, a free calculator wrapping the real pricing code, a video and a social pack. One proof cluster written in full.
Number, email, memory, presence, reputation. The keystone bet self-refuted within a session of being committed, because tradesmen keep their own phone number.
I am showing this deliberately, and not as a roadmap. It is the shape of what the grind actually bought. The real return on Van Brain was never going to be Van Brain. It was learning the stack properly, learning how to build with AI agents rather than read about it, learning to test an idea and kill it, and learning to hold a long-term strategy loosely enough to abandon it. That meta-learning is the thing I took out of it, and it is why the graveyard is worth looking at rather than hiding.
The art direction was written as a set of bans before a single frame was made: no smiling stock tradesmen, no staged thumbs-up, no glossy sheen, no glowing circuits or holograms to signal "AI", no clean studio backgrounds, no props that are not a working spark's actual kit. The product is an assistant, not a saviour, and the imagery had to behave accordingly.
Two tradespeople entered the funnel; only one, Harvey, ever sent it to a real customer. He paid on 11 June, on a discount steep enough that no money ever actually changed hands, and was never activated: a mismatched security credential between two systems left the activation silently dead for twelve days, then an old, leftover part of the sign-up process corrupted his profile and crashed the system. The recovery took a full session with multiple AI agents working together, and thirteen rounds of code fixes, numbered 689 to 703. Then came the pilot's actual killer: Harvey forwarded a client's itemised email brief for a garden office, and the system smoothed the detailed brief into a generic summary instead of keeping the itemised detail intact, the customer's own detail lost.
Charlie, the second tradesman, never completed a real pilot session; his sharpest use was as a founder-driven dogfood account, and it caught the worst bug in the project on its own: ten explicitly priced materials silently collapsing into six generic categories at quantity zero, a £135.60 wrong quote on an £800 job. Caught before it ever reached a customer, which is the whole point of building the scorecards in the first place.
The deeper problem was the order I did things in. My own audit flagged demand as the number one risk on the fourteenth of May, and I kept building for three more weeks. The single largest category of merged work was not any code surface: it was documents and strategy, at just under a third of everything. The one cheap way to test whether anyone wanted this, a waitlist and a few pounds of ads, sat at the top of my own morning briefing as the highest-leverage unclaimed task for twenty consecutive days and I never ran it.
The honest verdict on the product idea came out of the testing. My builders did not want a better chat interface. They wanted a magic machine, materially smarter than anything generally available, and the only route to that is a team of agents sitting on proprietary pricing data. Which means merchant partnerships, a large customer base to generate the data in the first place, and a great deal more tooling in a domain that is not my profession. Plenty of people would have liked the invoicing app. Liking an invoicing app is not a moat.
The commercial figures stay off this public page by choice. Every visual on it is public-safe demo data or the project's own test fixtures, never a live customer export.
So I moved the weight of the quote from the tradesperson to the customer. An AI configurator generates the design and most of the quoting work up front, solves pricing partially rather than pretending to solve it completely, and earns its keep on lead generation instead of on being cleverer about materials than a merchant. It is comfortably inside what current AI tools do well, it is more scalable than a system that lives or dies on one trade's proprietary pricing data, and it is much more my profession than building is. Every architectural idea on this page went with it.