MVP Development

What an MVP is, and what it is not

MVP stands for minimum viable product. It is the smallest version of a product that lets real people do the one thing it exists for. It is not a rough draft of the finished product, and it is not a demo built to impress investors. It is a working tool that a real user can try, judged on whether they come back and use it.

The point is to learn cheaply. Every feature you leave out is money you do not spend on something nobody wanted. An MVP gives you an answer to the question that matters most before you commit to a full build: will people use this?

We build MVPs as web applications. We do not build native iPhone or Android apps for an MVP, because a web app that works well on a phone is faster to put in front of people and cheaper to change when you learn something.

Cut the idea to the one job it must do

Most ideas arrive as a long list. The app should do this, and also that, and eventually it should also handle the other thing. The first job of an MVP is to cut that list down to one job. Which single task, for one kind of user, does the product have to do for the idea to be worth anything?

We work through this with you on a discovery call and in a short scoping session. We ask who the user is, what they are doing right now without your product, what makes that painful, and what would make them choose yours. The answers usually shrink the list quickly.

• The user: one specific person, not everyone who might benefit.
• The job: one task they want done, described in their words.
• The trigger: what makes them need it now rather than someday.
• The success signal: what the user does that tells you the job worked.

Build that one job properly

A common mistake is to treat an MVP as permission to build something sloppy. It is not. Users judge the one job you give them, and if that job is clumsy, they leave, and you learn the wrong lesson. The job has to work reliably, look credible and handle the obvious mistakes.

So the core flow gets proper attention. Sign-up or access works. The main screens are clear. Errors are explained in plain language. Data is saved correctly, so a user who returns finds their information still there. Everything outside that flow can be rough, and often is.

• The core flow is complete from the first click to the outcome.
• Logins and access are set up properly, even if the screens around them are simple.
• Inputs are checked, and users see clear messages when something goes wrong.
• Usage is recorded, so you can see what people did and not only what they said.

AI tools help us build the first version faster. Every line that goes into the product is reviewed by a senior person before it goes live, because a fast MVP that breaks in front of the first users teaches nothing useful.

Put it in front of real users

An MVP only tests anything when real users try it. Friends who are being polite do not count, and neither do people who said they would sign up in a survey. We help you find a small group of people who match your user, and we set up the test so you can see what they do.

The group should be small enough to talk to and specific enough to matter. Ten people who have the problem every day will teach you more than a thousand visitors who clicked out of curiosity. We agree who the test group is before launch, and how you will reach them.

Watch what they do, not only what they say. Where do they stop? Which button do they ignore? Do they come back the next day without being asked? Those answers are the ones that matter for the decision.

What you learn, and how you decide

At the end of the test, you have a short set of answers. Did the right users reach the core job? Did they complete it? Did they come back? What did they ask for that you did not expect? Each answer points to a decision.

• Keep going: users complete the job and return, so the next build is worth funding.
• Change direction: users want the job but do it differently, so the plan needs to change before the next build.
• Stop: users do not come back, and the honest result is that the idea needs more thought or should be dropped.

We write the decision criteria before the test starts. That stops the result being bent to match what you hoped to see. A clear no is a good outcome for an MVP, because it saves the cost of the full build.

MVP build vs full product build vs a landing page test

Before spending on a build, many founders consider a landing page with a sign-up form. That tests interest, which is useful but limited. Here is how the three approaches compare.

A landing page is the cheapest first step, and it still makes sense if you have nothing to show yet. Once people need to do the job, rather than say they like the idea, an MVP is the test that counts. A full product build only makes sense after that test has told you where to aim it.

What an MVP leaves out, honestly

An MVP is incomplete by design. It will not have every feature people ask for, and some of the things they ask for will turn out to be wrong. It will not look like a finished product in every corner, and some screens will be plain. It may not scale to thousands of users on day one.

These gaps are the trade. The question is whether the gaps stop the test from answering the main question. If they do, the scope is wrong. If they do not, they are acceptable, and we will say which ones are open so you can decide with your eyes open.

Why start small

Money spent on a full build is hard to get back. Money spent on a focused MVP buys an answer. If a short, focused test can answer what a full build would take far longer to answer, the cost of the MVP is small compared to the decision it informs. Timelines are scoped and dated on the discovery call, so you know the shape before you commit.

We quote the MVP after a discovery call, based on the one job we agree and what it touches. There is no standard package, because one job can be simple and another can need a lot of care around data and access.

If you are not yet sure which idea deserves the test, an AI consulting review can rank your options first. It is a useful step when you have several ideas and no clear winner.

Test users and their details

Real users in a test mean real details: names, contact information and whatever they type into the tool. We only collect what the one job needs, and we talk through how test data is stored and removed before launch. The privacy policy sets out what we collect through this website.

If your MVP will hold sensitive information, such as health, legal or financial details, we say so on the discovery call. Some of those cases need more care than an early test should carry, and we will tell you if that is the situation.

When an MVP is the wrong move

An MVP is not always the answer. If the idea is already proven in your business, because your team does the job every day and the demand is clear, a test adds little. Build the tool for the process you already run.

It is also the wrong move if the test would need a large audience you cannot reach, or if the product only works when everything is perfect from the start, such as a hardware-dependent service or a regulated process. We will say so rather than build something that cannot answer its own question.

What happens after the test

Once the test has run, we review the results with you against the decision criteria agreed at the start. You leave with a clear next step, whether that is a larger build, a changed plan or a stop. The code and the findings are yours, so you can take them to another builder if you prefer.

If you go ahead, the MVP becomes the foundation for the next stage rather than something thrown away. Choosing which parts to keep is part of the review. You can book a discovery call to start the conversation.