From idea to MVP in weeks: how to de-risk a new product

Every new product starts with more assumptions than facts. You believe a certain group of people has a certain problem, that they will try your solution, that it will work well enough, and that someone will pay for it. Each belief could be wrong — and building the full product before testing them is the most expensive way to find out.

A minimum viable product (MVP) exists to replace assumptions with evidence as quickly and cheaply as possible. Done well, it gets a real product into real hands in weeks. Done badly, it becomes a slow, half-finished version of a product nobody validated.

An MVP is a test, not a smaller product

The most useful reframe: an MVP is the smallest thing you can build that tests your riskiest assumption with real users.

That changes the questions you ask. Not "which features can we fit in?" but:

• Which assumption, if wrong, kills the business?
• What is the least we need to build to find out?
• What will we measure, and what result would change our plans?

Sometimes the answer is a full working app. Sometimes it is a landing page, a clickable prototype, or a service delivered manually behind a simple interface. The right MVP is the one that produces trustworthy evidence fastest.

Step 1: Name the riskiest assumption

Write down everything that has to be true for the product to succeed, then rank each by two questions: how uncertain are we? and how bad is it if we're wrong?

Common candidates:

• Desirability — do people actually feel this problem strongly enough to change behaviour?
• Usability — can they understand and use the solution without help?
• Feasibility — can it be built at the quality required (especially relevant for AI-powered features)?
• Viability — will someone pay enough, often enough, at an acceptable cost to acquire?

The assumption at the top of that list is what your MVP is for.

Step 2: Cut scope ruthlessly — and deliberately

Scope is where MVPs go wrong. Every stakeholder has a feature that "obviously" has to be there. A simple discipline helps: for each feature, ask does this help test the core assumption, or is it needed for users to complete the core journey? If neither, it waits.

What usually stays in:

• The one core journey from first use to the moment of value.
• Enough onboarding to get users to that moment without a guide.
• Basic trust signals — a clear privacy approach, sensible security, a way to contact you.
• Measurement of the behaviours that test your assumption.

What usually waits: settings screens, admin dashboards beyond the essentials, multiple user roles, integrations that can be done manually at first, and polish on journeys that few users will reach.

Step 3: Design before you build

A clickable prototype is the cheapest place to make mistakes. In a few days you can put realistic screens in front of five to eight target users and learn whether they understand the value, follow the journey and trust the product.

What we look for in these sessions:

• Can they explain, in their own words, what the product does for them?
• Where do they hesitate, misread or get stuck?
• What do they expect to happen next at each step?

Fixing those issues in design takes hours. Fixing them in code takes weeks.

Step 4: Build for speed now, and for growth later

Engineering choices in an MVP should optimise for learning speed without creating a dead end.

• Use proven, productive tools. Cross-platform frameworks such as Flutter or React Native, managed backends and hosted authentication let a small team ship a lot. Save custom infrastructure for when you know you need it.
• Keep the architecture clean. Separate the user interface, the business logic and the data layer. This costs little extra time and makes later change far cheaper.
• Automate the boring safety nets. Automated builds, a test suite for the core journey and error monitoring pay for themselves within the first weeks.
• Instrument from day one. Track the events that test your assumption — not just page views.

The aim is a codebase you can grow into version two, not one you will have to throw away.

Step 5: Launch small, learn fast

Launch to a focused group first: a waitlist, a pilot customer, a single market. A small group you can talk to is worth more than a large audience you can't.

Measure what matters for your assumption:

Pair the numbers with conversations. Analytics tell you what happened; users tell you why.

Step 6: Decide, then iterate

After a few weeks of real usage, make an explicit decision:

• Persevere — the evidence supports the assumption; invest in the next most important capabilities.
• Pivot — something is working, but not as expected; change the audience, the problem or the solution.
• Stop — the core assumption was wrong. This is a successful MVP too: it saved you months.

Then repeat the loop with the next riskiest assumption.

How long should it take?

There is no universal number, but for a focused product with one core journey, a realistic shape is:

1. Discovery and scoping — about a week to align on the problem, users, assumptions and success metrics.
2. Design and prototype testing — one to two weeks, including user sessions.
3. Build — typically four to eight weeks, in weekly increments you can see and use.
4. Pilot launch — then continuous improvement based on evidence.

The fastest projects share one trait: a decision-maker who is available every week and willing to say "not yet" to good ideas that don't serve the test.

The bottom line

The goal of an MVP is not to launch something small. It is to learn something big, quickly, with the least waste. Name your riskiest assumption, cut everything that doesn't test it, design before you build, and launch to people you can learn from.

Have an idea you want to test properly? Tell us about it — we'll help you find the riskiest assumption and the fastest honest way to test it.