The Over-Engineered v2
The first time we showed the Mad-Max image to a logistics operator I will call the dispatcher here, he laughed for longer than the joke warranted. Then he said, that is my app. Then he showed us his app.
That image is the leftmost frame of the AI row of the three-row picture from Three Circles and Three Arrows. A green contraption, driver seated, two mis-matched exhausts, a roof rack loaded with something that might be a spare chassis or might be a barbecue. A welded lance along the bonnet, three antennae where one would do, a cartoon face on the radiator. It moves. A person could get in and drive it from one town to the next, provided the road was straight. Anyone looking at it can see, at the same time, that it is functional and that it is absurd. Both readings are correct. Both readings are the point.
For the first fifteen years of the studio we met clients at the blank page. They arrived with nouns, and we converted the nouns into screens. Every process we had, from the scoping checklist through to the acceptance matrix, was scaffolding around a single problem: the founder could picture a finished thing and could not describe it. Our job was to coax the picture out of them, one question at a time, over enough weeks that the picture stabilised and could be built. Murray and his paddocks sit at the start of that tradition. The more recent enterprise engagements sit near the end.
The founder has always been imagining v2. What has changed is that the founder can now externalise v2 on a weekend, for the cost of an API subscription, and hand us the artefact instead of the description.
A different founder’s repository hits my inbox at 7:40 on a Monday morning in March. The subject line reads weekend project — can we talk? and there is a link to a private GitHub organisation and a green Vercel build. The repo has forty-two commits across a single branch, most of them from Saturday and Sunday, most of them authored by a default Claude Code username the founder has not yet changed. Sign in with a throwaway email, and there is a working dashboard with seventeen top-level menu items, four of which go somewhere real, three of which show placeholders and ten of which the founder has not finished wiring up. I open a blank page out of habit, close it and start reading code instead.
That artefact is not a rough sketch. It is not v0.1. Sliday spent most of 2024 expecting v0.1: we kept opening repos and looking for the missing pieces the way we used to look for the missing pieces in a wireframe. The repos did not have missing pieces in the way we were trained to notice. They had too many pieces. Too many features. Too many menus. Too many half-working screens. They looked, when you opened them, like a product that a small team might have shipped two years into the life of a Series A, not like a prototype.
I have come to think of what lands on Monday morning as an over-engineered v2 of an unfinished v1.
The dispatcher had been running a regional freight business for years, and trying to get a scheduling tool built for almost as long. More than one studio had quoted the work and produced one of three outcomes: a proposal he would not sign, a half-built product he would not ship, or nothing at all. He had taken a Claude Code subscription, watched the YouTube tutorial twice and built a working scheduling tool over a couple of weekends. When he sent it to us, the left-hand navigation had seventeen top-level items: Dispatch, Fleet, Drivers, Loads, Routes, Customers, Invoicing, Compliance, Fuel, Incidents, Maintenance, Shifts, Documents, Messages, Reports, Analytics, Settings. Several of them had sub-menus. One of them had sub-sub-menus.
We opened each menu, one at a time, across a long call. The question for each one was the same. Does this earn its place in the first shipped version. Four of them (Dispatch, Drivers, Loads, Invoicing) were obviously load-bearing. He used them. His staff would use them. Without them, the product did nothing. One of them, a light version of Compliance, bore weight in a quieter way: the freight industry runs on document deadlines, and a tool that did not surface those would be a toy. That took us to five.
The other twelve were not rubbish. Several of them were genuinely good ideas. Maintenance-by-odometer, route-profitability analytics, an in-app message log: each one had a reason to exist. Each one was also the second version of a feature whose first version had not yet been through a single real week of use. Shipping any of them now would not help the dispatcher learn what his product actually was. Shipping any of them now would make the product harder to look at, harder to use one-handed in the cab of a truck and harder to finish.
We wrote five on a whiteboard and twelve on a different whiteboard. We gave him the second whiteboard as a backlog, dated, with the note that nothing on it should be built until the first whiteboard had been in production for ninety days and the product had told us what was missing. He agreed in the same call. He was not defensive. Later, in a quieter moment, he said the thing that I think every founder who has built their own v2 feels and only half of them will say out loud. He said he had been waiting years to be told which twelve to cut, and that every studio before us had spent their time asking him what he wanted built.
It is worth saying that the Mad-Max pattern is common, not universal. A physiotherapist sent us a repository last year that had the opposite shape. Four routes. One table. One login flow. A landing page with two sentences on it and a booking form underneath. She had watched the same tutorial everybody else had watched and had cut, on her own, most of the features it had suggested, because she knew from years of clinic bookings which four she would use in the first month. The repo was a few hundred lines of code. Reading it took the senior a morning, and the scoping call that followed was about which three of her four routes needed hardening for real card payments and which one, the messaging thread, should wait. A sculptor’s first instinct is to reach for the shears, and sometimes the garden is already trimmed. We read for that too.
In the triage call, draw two columns on a whiteboard before you open the repo: one for features that ship in version one, one for features that wait. Fill the second column first. Any feature that cannot survive the question “what breaks for the user if this is absent on day one?” goes into the wait column. The founder will argue for some of them; that argument is useful data about what the product is actually for.
The old studio asked what to build. The new studio asks what to cut. One question is a guess; the other is an edit. An edit is cheaper than a guess, always, everywhere, in every field that has ever had both. We have started calling this work sculpting, for reasons the book will get around to defending later; the verb is the important part.
For the studio owner running the numbers, the useful part of this is the cost side.
The old discovery phase at Sliday took billable studio time before a single line of production code was written. Much of that effort went into extraction: the calls, the re-sketches, the notebook pages of unfamiliar vocabulary. A scoping document on the Murray model was a genuine artefact, and the price reflected the craft involved in producing it.
The prototype-as-brief reduces that effort, but not evenly. The extraction is gone: the founder has done it for us, in code, over a weekend. Where the Murray reconstruction illustrates a long extraction phase, the dispatcher took us about four working days, across two calendar weeks, to read the repo, walk the menus, separate the five that ship from the twelve that wait and return a costed plan. We call that reading-and-cutting work a triage. It is not a separate product with a price tag; it is the few days of a senior’s attention that now stand where weeks of extraction used to. More than one has saved a founder tens of thousands in scope before anyone wrote a ticket.
The work that follows a triage is not cheaper overall. Hardening a weekend codebase into something a regional business can depend on is expensive, and a sceptical CTO reading this chapter is right to keep their hand on the brake. Licences of generated code, auth scaffolding assembled from three different tutorials, secret management done in a .env file that was briefly committed to git: each of these is a production tax that the weekend repo has postponed rather than paid. From Builders to Hardeners deals with hardening as its own discipline. Who Warrants What deals with the contract clauses that make the production tax someone’s explicit responsibility.
Run the hardening pass in a fixed sequence every time: input validation, authentication, secrets management, rate limiting, then error handling. Skipping one does not remove the risk; it moves the cost to an incident. The sequence is not a style choice — it is the order in which weekend codebases most commonly fail in production.
None of that changes what has arrived: a Mad-Max car, in a repo, on a Monday morning, with its weapons welded on and its driver laughing.
There is a tempting mis-reading of what I have just described, and we have watched more than one studio fall into it. The mis-reading is that the over-engineered prototype is a problem: that the job is to dismantle it and start again properly. That prototype is a gift. The founder has spent a weekend doing the single most expensive piece of work a founder can do for a studio, which is deciding, in detail, in their own voice, what they think the product should feel like. The fact that they have got twelve of the seventeen answers wrong is evidence that the method has worked. Twelve wrong answers, specified to the point of clickability, are worth more to a studio than one right answer described in a brief.
A sceptical reader will not be persuaded by the enthusiasm, and should not be. The honest measured claim is narrower than the enthusiasm sounds. We do not claim that every founder’s repo is worth triaging. We do not claim that the first version of the prototype is what ships. We do not claim that the studio’s work shrinks, in hours or in revenue; only that it moves (from extraction to editing, from guessing to cutting, from describing absent screens to reading present ones). The observation is: for roughly the last eighteen months, the repos that arrive on Monday mornings have been over-built rather than under-specified, and the studio that learns to read them quickly and cut them honestly is the studio the founder calls back.
The studios that cannot, or will not, read them this way are already visible in the market. They quote the triage as a six-week discovery. They rewrite the prototype from scratch because the stack is unfamiliar. They tell the founder that the work they did on the weekend was not really work. That last one, in particular, is a tell, and it is the fastest way I know to lose a client who has, by weekend’s end, fallen quietly and properly in love with their own creation.
The new starting point is not a blank page but an overgrown garden, and the first tool you reach for is shears.