Home/MVP Development/Guide
The MVP Guide
The guide we wish
existed when we
started shipping.
Most MVP advice is generic, written by people who have not built one under real pressure. This is the opposite: an honest field manual on what an MVP actually is, what decides whether it works, and where founders waste their first build.
The short version
An MVP is a question,
not a small product.
Everything in this guide comes back to one idea: an MVP exists to answer a single question as cheaply as possible. Once you hold that, every decision, scope, cost, timeline, tech, gets easier, because each one is judged against whether it serves the question or just feels important.
What it is
What minimum actually means
The phrase minimum viable product is misread constantly. Founders hear minimum and think cheap, or small, or unfinished. None of those is right. Minimum means the least you can build to test one specific assumption about your business, the single thing that has to be true for the idea to work.
That definition is ruthless on purpose. If a feature does not help test the assumption, it is not minimum, no matter how reasonable it sounds. The settings page, the second user type, the polish, they all wait. What is left is usually uncomfortably small, and that discomfort is the signal you have done it right.
Viable matters as much as minimum. The product has to actually work, for real users, well enough to produce a real signal. A broken thing teaches you nothing except that it is broken. So an MVP is the narrowest slice of working software that can answer your riskiest question.
The cutting
The whole discipline is subtraction
Every founder arrives with a feature list that is too long. Not because they are foolish, but because every feature feels necessary when you can picture the finished product. The hard, valuable work of an MVP is deleting most of that list, and it is the part founders resist most.
Here is the test that cuts cleanly: for each feature, ask what you learn if you ship without it. If the answer is the same thing you would learn with it, cut it. The MVP keeps only the features whose absence would stop you testing the core assumption. Usually that is a startlingly short list.
This is also where an experienced partner earns their fee, by saying no. Left alone, founders build too much, every time. Much of what you pay for is someone with the standing to push back and protect the build from its own scope creep.
Cost
What it costs, and why the range is so wide
Genuine MVP builds run from roughly 10,000 to over 100,000 GBP, and the spread confuses people. It is wide because MVP is not a defined unit of work. One quote is a clickable prototype, another is production software with auth, billing, and deployment. One is junior offshore hours, another is senior local delivery. The numbers are not comparable until you know what each includes.
The cheap-is-expensive trap is real. A build on no-code or junior hours with no architecture often hits a ceiling within a year and has to be rebuilt, at which point the headline saving is paid back with interest. Cheap is only cheap if you never need to scale, which rather defeats the point of validating something you hope will.
The honest way to read a quote is to ask what is delivered: real code or a prototype, who owns it, what stack, deployed to production or not, fixed or hourly. Two numbers only mean something once you know they describe the same thing.
Timeline
Why eight weeks, and why six months is a red flag
An MVP should reach real users in around eight weeks. The logic is simple: the point is to learn fast, and a timeline measured in months is, by definition, not fast. If a first version is quoted at half a year, the scope is almost certainly a full product wearing an MVP label.
The factor founders underestimate most is their own decision speed. A build waits on the founder for answers and sign-off, so slow, hesitant decisions stretch a timeline far more than the engineering ever does. The fastest builds have a decisive founder, not just fast developers.
Beyond that, the timeline moves on scope: more user types, an admin panel, integrations, mobile as well as web. All real, all honest about their cost in time. None of which changes the rule that the way to ship sooner is to cut, not to rush.
Build vs buy
No-code, real code, and choosing deliberately
The no-code versus real-code question has a clean answer once you frame it correctly. It is not about which is better, it is about which question you are answering. No-code answers does anyone want this, fast and cheap. Real code answers can I own and scale this, properly and permanently.
Using the wrong one wastes either money or time. Real code to test a flimsy, unproven idea burns budget on a question you could have answered in a weekend. No-code to build a product you fully intend to scale stores up a rebuild you will pay for later. Match the tool to the risk you are actually retiring.
Many founders take the sensible middle path: no-code or a landing page to confirm interest, then real code once demand is proven. There is no shame in that sequence. The mistake is committing to expensive, permanent foundations before you know anyone wants the thing at all.
After launch
Shipping is the start, not the finish
The most quietly damaging MVP mistake is treating launch as the end. Founders pour everything into shipping, celebrate, and then stop watching. But the MVP launching is the exact moment its actual job begins: producing a clear signal from real users about whether the assumption held.
That signal is behaviour, not words. Users are kind in interviews and honest in usage. Watch what they do, where they drop off, what they ignore, what they come back for. The MVP exists to turn those observations into one decision: double down, change direction, or stop.
If your build does not produce that decision cleanly, it was not focused enough, and that itself is a lesson worth having early. A good MVP ends with a founder who knows something true about their business that they did not know eight weeks earlier.
FAQ
Questions, answered straight.
What actually makes an MVP minimum?
Why do MVPs usually fail?
How much should an MVP cost?
How long should an MVP take?
No-code or real code?
What is the single most useful thing in this guide?
Keep reading
Ready
You have the thinking.
Now build the thing.
If you would rather not build it alone, tell us the one question your product needs to answer. We will scope it, price it, and ship it in eight weeks.