VISUOSOFTS · WEB DEVELOPMENT
Most startups do not fail for lack of ideas — they fail building the wrong thing brilliantly. An MVP (minimum viable product) is the discipline that prevents it: the smallest thing you can build that tests whether anyone actually wants what you are selling. This guide explains why you should build one, what counts as an MVP, and how to do it without the usual waste.
Written for UK founders: practical, honest about the trade-offs, and focused on learning per pound spent.
WHY BUILD AN MVP — THE EXPENSIVE ALTERNATIVE
The expensive alternative is building the full vision on assumptions: twelve months of development, a launch, and the discovery that customers wanted something adjacent to what you built. We have watched this story enough times to know its shape — the founders are always surprised, and they should not be, because nothing in the process tested the core assumption. An MVP exists to make that discovery cost weeks instead of a year.
The economics are stark: an MVP typically costs 10–20% of the full build but answers 80% of the riskiest questions — will anyone use this, will they pay, what do they actually value? That is the cheapest risk reduction available to a startup. Investors know it too: "we validated with an MVP used by 200 paying customers" beats any pitch deck. For the hands-on companion, see how to build a minimum viable product.
WHAT COUNTS AS AN MVP (AND WHAT DOESN'T)
An MVP is not a buggy half-product — it is a complete solution to one problem for one user type. The "minimum" refers to scope, not quality: it must work reliably for its narrow job, because a broken MVP teaches you nothing (users leave over the bugs, not the concept). The "viable" means someone gets real value — enough to use it, ideally enough to pay.
MVPs come in flavours: the concierge MVP (deliver the service manually behind a simple front — tests demand with almost no build), the Wizard of Oz (looks automated, humans behind the curtain), the single-feature product (one job, done well), and the landing-page MVP (tests willingness to sign up before anything is built). Choose the flavour that tests your riskiest assumption cheapest. If the risk is "will anyone want this?", a landing page beats six months of code.
SCOPING IT RIGHT — THE HARDEST PART
Scoping an MVP is an exercise in ruthless subtraction. List every feature of the vision, then ask of each: "if we cut this, can we still test the core assumption?" Cut everything that survives the question. Founders consistently overscope by 3–5x — the discipline is to ship the version that embarrasses you slightly, then learn from real users instead of debating hypotheticals.
Define the learning goals explicitly before building: what must we learn, and what metric answers it? "Validate demand" becomes "200 signups from the target segment at £X CAC" or "40% of trial users completing the core workflow weekly". Without defined learning goals, the MVP drifts into a small product nobody measures — which is just a slow, expensive way to avoid learning. Write the goals down; they are the MVP's specification.
BUILD FAST, BUILD LEAN
Speed is the MVP's virtue — every week of building is a week of not learning. Use the fastest stack that can deliver the scope reliably: proven frameworks, managed services, off-the-shelf components wherever they do not compromise the test. This is not the time for exotic architecture or perfect code; it is the time for working software in users' hands. Technical debt is acceptable in an MVP if it is conscious and documented — you are buying speed with a known IOU.
Choose builders who understand MVP discipline — the instinct to gold-plate is strong in developers who have never watched a startup die of overscoping. Time-box the build (6–12 weeks is the healthy range for most software MVPs) and protect the scope against the inevitable "just one more feature" pressure. Our app development team builds MVPs to this discipline: fixed scope, fixed timeline, learning goals first.
MEASURE LEARNING, NOT VANITY
Instrument the MVP for its learning goals from day one: activation (do users complete the core action?), retention (do they come back?), and the money question (will they pay, or take the next step toward paying?). Ignore vanity metrics — total signups without activation, page views without engagement — they flatter and mislead in equal measure.
Talk to users relentlessly alongside the numbers: watch them use it, ask what nearly stopped them, find out what they would miss if it vanished. The quantitative tells you what; only conversation tells you why. Review weekly against the learning goals, and be prepared for the three outcomes: persevere (it works — scale it), pivot (the insight points elsewhere — the MVP did its job), or stop (nobody wants it — the cheapest failure you will ever have).
AFTER THE MVP — WHAT COMES NEXT
A successful MVP graduates: the validated core becomes the foundation, the learnings reshape the roadmap, and the technical debt gets paid down deliberately as you scale. Resist rebuilding from scratch unless the MVP's architecture genuinely cannot carry the next phase — working software with known debt usually beats a rewrite's unknown risks.
A "failed" MVP is often the most valuable outcome — a pivoted insight or a killed idea that cost weeks instead of a year. The only true MVP failure is building something nobody measured: no learning, just expense. Talk to us about your MVP — we will help you scope it ruthlessly and build it fast, and we will tell you honestly if the idea needs validating before a line of code.
STARTUP MVPs — FAQs
How much does an MVP cost?
Wildly variable by complexity — from a few thousand for a landing-page or concierge test to £30k–£80k for a functional software MVP. The discipline is spending the minimum that still tests the riskiest assumption properly. Get scoped quotes against defined learning goals, not against a feature wishlist.
How long should an MVP take to build?
Six to twelve weeks for most software MVPs. Longer than that usually means the scope crept — revisit the learning goals and cut. Speed matters because every week building is a week not learning from real users.
Should the MVP be polished?
Polished enough to be usable and trustworthy for its narrow job — never buggy or embarrassing in reliability. But visual perfection and edge-case completeness can wait. Users forgive rough edges when the core value is real; they do not forgive broken promises.
What if nobody uses the MVP?
That is data, not disaster — provided you can say why. Distinguish distribution failure (nobody heard about it) from product failure (they came, they left). Fix distribution first; if they came and left, interview them hard. The cheapest failure is still a success if you learn.
Can we skip the MVP and build the full product?
You can, and occasionally the vision is clear enough to justify it — but be honest about whether that clarity comes from evidence or enthusiasm. The founders who skip MVPs successfully are usually on their third startup, with pattern recognition earned the expensive way.
