You have something you want built. A first version of a product, or the system the business has outgrown its spreadsheets for. Somebody has probably quoted for it already, and the quote will not have explained much.
This page is what happens between the idea and something people use for real work. It is the same sequence whether you build it with me, with an agency, or with somebody you hire. Knowing the sequence is most of what you need to tell a good quote from a bad one.
MVP stands for minimum viable product. The phrase came out of startups and has been stretched until it mostly means “cheap”. That is not what it is for.
An MVP is the smallest version of a thing that you can put in front of real users and learn something true from. The learning is the point. You build the part carrying the risk — the bit you are least sure about — and leave the rest alone until the answer comes back.
In an owner-run business the risk is rarely whether anybody wants the thing. You already know they do, because they keep ringing. The risk is usually whether the process can be made to work in software at all, and whether your team will use it on a busy Tuesday. So the MVP is one process, end to end, for real, with real data in it.
A prototype is a different object. A prototype exists to answer one question and is then thrown away. An MVP is the first version of something you keep and build on, which is why the decisions underneath it matter more than they look.
What goes into building one, in the order it happens.
Before anything is written, the sequence that happens today gets written down. Who touches the job, what they type, where it goes wrong, and what they do when it goes wrong. Half of what ends up in a brief turns out to be a workaround for something else, and that half does not need building.
Whether to configure something off the shelf or build it. Which database. Where it runs. These are cheap to decide now and expensive to change in a year, and most of them come down to what the business will still be doing in three years.
What a job is. What a customer is. Whether a booking can exist without one. This is the most common reason a build stalls at eighty per cent: the shape of the data does not fit the way the business works, and every new screen fights it.
A single complete path through the system, working, with real data in it. Screens with invented numbers on them prove nothing. Somebody in the business should be able to do one real job in it, start to finish, before anything else gets built.
A week of real use tells you more than three months of specification. Things will be wrong. That is what the step is for, and it is why the thin slice comes before the rest of the build rather than after it.
The code, the accounts, the domain and the data, written down plainly enough that another developer can pick it up cold. Agree what the handover includes before the first line is written, while it is still uncontroversial.
Everybody wants a number first. It comes out of five things, and none of them is how many screens there are.
Something that stands on its own is straightforward. Something that has to stay in step with your accounts package, your booking system and a supplier feed is a different job, and most of the work lives in the seams between them.
If nobody can tell me what a job is without starting the sentence "well, it depends", that is discovery. Discovery is real work and it takes as long as it takes. It is also the part that saves the most money.
One owner deciding takes an afternoon. Four departments with a view on it takes as many weeks as it takes, and no amount of engineering speeds that up.
Payments, health data and anything sitting under FCA rules add real work to the build and to the testing. None of it is optional and none of it can be added at the end.
Something you will run for five years is built differently from something you expect to replace next year. Both are legitimate. Deciding which one you are paying for changes what gets built.
Four patterns, all of which are visible early if you know to look.
Every build has changes. The ones that ship are the ones where adding something meant taking something else out of this phase. When nothing ever comes off, the launch date stops meaning anything and everyone quietly knows it.
A specification signed off in a meeting is a set of guesses about how people work. Some of them are wrong. The ones that are wrong are only found by putting the thing in front of somebody who does the job.
This is the most expensive pattern in the industry, and it is invisible from outside. Ask who will actually be writing the code, how long they have been doing it, and who reviews their work.
No access to the code, no documentation, a hosting account in someone else’s name. The build works, and you cannot get another developer to touch it without starting again. Agree the handover before the first line is written.
I ran technology inside Watchfinder from employee number four through to CTO and CIO, past the Sunday Times Fast Track 100 and the Richemont acquisition. I now build first versions for businesses that have nobody senior on the technology side.
I do the building. There is no team behind me to hand it down to, which puts a hard limit on how much I take on and is why I work with a small number of clients at a time. You deal with the person writing the code.
AI is part of how I build now, and it has genuinely changed what a first version costs and how quickly one can be standing up. I do not sell it as a thing on its own, because on its own it does not do anything for your business.
Work is bounded, phase by phase, and you own what gets built — the code, the accounts, the domain and the data.
A few lines about what you're stuck with. You don't need a defined project or a brief. It comes straight to me and I'll come back to you to sort out a call.
Cass is an Agent I built to help you work out what to tell me. It asks a few questions and gets the detail down, so our first call is a productive one.