How to Build an MVP Without Building the Wrong Thing

Most advice about building an MVP is written for startups. It assumes you are trying to find out whether anybody wants the thing at all, and that you have nothing to lose if the answer is no.

That is not the position you are in. You already know people want it, because they keep ringing you about it. What you do not know is whether the process can be made to work in software, whether your team will use it when they are busy, and whether the thing you have been quoted for will still make sense in three years.

So the advice needs adjusting. Here is what building a first version looks like when you have an operating business underneath it.

Start with the thing you are least sure about

An MVP exists to remove your largest unknown. Everything else in the plan can wait.

That sounds obvious and it is routinely ignored, because the largest unknown is usually the uncomfortable one. If you are honest, the risky part of your project is rarely the customer-facing screen. It is the bit where the job comes out of one system and has to arrive correctly in another, or the bit where five people currently hold a rule in their heads that nobody has ever written down.

Build that part. Build it badly if you have to, with an ugly interface and no login, but build the part that has to be true for the rest to work. If it turns out to be harder than anyone expected, you have found that out in week three rather than month five.

The corollary is that anything you are already confident about is a candidate to be cut from the first version. You do not need to prove that a form can save a record.

Choose one slice, all the way through

The most useful shape for a first version is one complete path through the system for one real job.

A booking comes in, gets priced, gets assigned, gets done, gets invoiced. One of those, working, with a real customer’s real data in it, is worth more than every screen half-built. It gives you something a person in your business can actually use on a Tuesday morning, and their reaction to it is the only reliable information you are going to get.

The alternative, which is what most projects do, is to build every screen to seventy per cent. That produces months of visible progress and no usable software, and it hides the integration problems until the end, which is the worst possible place to find them.

Write down what a thing is before anybody writes code

If you take one thing from this: get the data model right early.

What is a job? Can a job exist without a customer? What happens when a customer becomes two customers because they set up a second company? Is a quote a different object from a job, or the same object in a different state?

These sound like pedantic questions. They are the questions that decide whether the build stalls at eighty per cent. When the shape of the data does not match how the business actually works, every new screen fights it, every report needs a special case, and the developer starts saying “we can do that, it’ll just take a while” about things that sound trivial to you.

The tell is when nobody can answer one of these questions without starting the sentence “well, it depends”. That is not a sign that your business is unusual. It is a sign that the rule exists in somebody’s head and needs to come out before it gets built around.

Put it in front of somebody who does the job

A week of real use tells you more than three months of specification.

Specifications are guesses about how people work, and some of the guesses are wrong. The ones that are wrong are only ever found by watching somebody try to use the thing while the phone is ringing. They will do something you did not anticipate within the first hour.

Plan for that. The point of building one slice first is that you get to this moment early, while changing your mind is still cheap.

What to cut, and how to decide

Every build has changes. The ones that ship are the ones where adding something meant taking something else out of this phase.

When you are asked to approve a new feature mid-build, the question to ask is not whether it is a good idea. It almost always is. The question is what is coming out to make room for it. If the answer is “nothing, we’ll fit it in”, the launch date has quietly stopped meaning anything and everybody in the room knows it.

Keeping a visible list of what has been deferred is worth more than it sounds. It stops the conversation being about whether somebody is being difficult, and makes it about sequencing.

Know what finished looks like before you start

An MVP is finished when the unknown it was built to remove has been removed. Write down, in advance, what you expect to learn and what you will do with each answer.

“We will know whether the engineers will use it on site” is a finishing condition, because you can tell when it has been met. Without one, an MVP has no end, and it turns into a normal build with a smaller budget and the same scope.

Where AI has genuinely changed this

It has changed how quickly the first version can exist. Work that used to take a fortnight of typing now takes a couple of days, which means the slice can be built and put in front of somebody far sooner, and thrown away and rebuilt if it was wrong.

What it has not changed is the thinking. The data model still has to be right. Somebody still has to sit with the person doing the job and find out what actually happens. AI writing the wrong system quickly is worse than a slow developer writing the right one, because it produces more code to unpick.

If you want somebody to do this with you

I build first versions for businesses that have nobody senior on the technology side, and I do the building myself. The full sequence, including the things that change how long a build takes, is on the page about getting it built.

If you are not yet certain what needs building, or something in the business is not working and nobody can name it, that is a different job: working out what to do comes first, and it ends with a plan you can build from.