Have an MVP Built: From Idea to First Product in 8 to 12 Weeks

Most failed products did not fail on bad technology. They failed because too much was built before anyone knew whether anyone wanted it.

An MVP — Minimum Viable Product — is the answer to that. But it is not "a stripped-down version". It is the smallest thing that turns a concrete, risky assumption into a real answer.

What an MVP is — and is not

An MVP is not a half-finished product with missing buttons. It is a complete, usable piece of value for one use case, built to answer a question: do real users use this, do we solve a real problem, will someone pay for it?

The misconception "MVP = cheap and bad" produces a product nobody takes seriously. The right picture: a sharply scoped, working core you measure reality against — not a prototype in a shop window.

Why 8 to 12 weeks

Shorter than 8 weeks is usually a demo, not a usable product. Longer than 12 weeks loses the actual advantage: learning early, with real user feedback, before a large budget is committed.

DORA's 2024 Accelerate State of DevOps Report shows the mechanism behind it: small, frequent, tested deliveries are more stable and faster than large, rare ones. An MVP is the first application of exactly that principle at the product level.

The five cuts of a good MVP

1. One audience, not "everyone"

An MVP for "small and mid-sized companies in Europe" is not a cut. An MVP for "schedulers in food wholesale with under 50 employees" is one. The narrower the audience, the sharper the feedback.

2. One core function

Not the feature menu you wish for — the one thing without which the product is pointless. Everything else is version 2.

3. One success criterion, defined upfront

"Looks good" is not a criterion. "30 % of pilot users use the core function again in week 2" is. Without a metric defined upfront, an MVP is an expensive gut feeling.

4. A stop and a scale criterion

What has to be true for us not to keep building? That question separates an experiment from an uncancellable project.

5. A path from MVP to production version

An MVP whose code has to be thrown away was an expensive prototype. Well scoped, the MVP core is the base version 1 grows on.

A realistic 8–12-week flow

• Weeks 1–2: Nail down audience, core function, success criterion and stop criterion. A one-page product charter, not a 60-page spec.
• Weeks 3–8: Build the core — usable, not "demo-ready". Real data, real login, real workflow for the one use case.
• Weeks 9–10: Test with real pilot users, not your own team. Observe, do not explain.
• Weeks 11–12: Measure the success criterion against reality. Exactly one decision: scale, iterate or stop cleanly.

Build or buy applies in the small too

Before building an MVP, it is worth asking whether the idea needs custom development at all — see Custom vs Standard?. And an MVP is the cheapest way to get a defensible cost estimate instead of guessing one — see What does custom software cost?.

Checklist before the MVP

• Is the audience narrow enough for sharp feedback?
• Is there one core function — or a wish list?
• Is the success criterion defined upfront and measurable?
• Is there a stop criterion?
• Is the core usable, not just presentable?
• Does version 1 grow on the MVP code — or must it go?
• Do we test with real users, not internally?

Frequently asked questions

Is an MVP cheaper than the "real" product? At the start, yes. Above all it is lower-risk: it prevents putting a large budget into something nobody wants.

Is a click prototype enough? For UI feedback, yes. For "do people use this daily and pay for it", no — that needs a usable core with real data.

What if the success criterion is missed? Then the MVP did its job: it prevented an expensive misinvestment. A cleanly stopped MVP is a success, not a failure.

What happens after a successful MVP? The experiment becomes a product: same core, broader scope, harder operations, security and scaling requirements.

Conclusion

An MVP is not a cheap product but the fastest experiment that answers a real question. 8 to 12 weeks, one audience, one core function, one success criterion, one stop criterion — that replaces an expensive bet with a measurable insight.

Further reading

• Custom Software vs Standard Software for SMEs — does the idea need custom development at all?
• What Does Custom Software Development Cost? — the MVP as the cheapest way to a defensible cost estimate.

Next step

Have a product idea but don't want to make an expensive bet? Start with a short assessment of your requirements. Together we scope an MVP with a measurable success criterion — in weeks, not quarters.

Sources

• DORA, Accelerate State of DevOps Report 2024 — dora.dev
• Atlassian, Agile Project Management — atlassian.com
• Thoughtworks, Technology Radar — thoughtworks.com