From idea to MVP in weeks: a concrete method

An MVP (minimum viable product) is the smallest version of your product that can prove somebody wants it. Not a mockup, not a throwaway prototype: real software, usable, released. My conviction after 7+ years of building products: a well-scoped MVP goes from idea to working product in 4–8 weeks. Not six months. That short timeline is not a technical stunt. It is scope discipline. Here is the method I apply, step by step, along with the traps I see nearly every founder walk into.

What an MVP is really for

An MVP answers one question: is somebody using this product to solve a real problem? Everything else is secondary.

Many founders build to reassure themselves. More features, more screens, more settings. The result: six months of development, a tripled budget, and still no answer to the original question, because the market has not seen the product yet.

A good MVP flips the logic. It puts the core of the idea in front of real users as early as possible, and lets their behavior, not their politeness, dictate what comes next. You learn more from two weeks of a live product than from six months of meetings.

Cutting scope without killing the idea

This is the hardest step, because it demands giving things up. My rule: an MVP contains one main user flow, complete and polished, and almost nothing else.

Concretely, I ask three questions about every proposed feature. Does the product make sense without it? If yes, it waits. Can a manual process replace it? A hand-written email does the job of a notification system perfectly well at the start. Does it serve the main test? If it does not help verify the central hypothesis, it goes.

What never gets cut: the reliability of the main flow, and the first impression. An MVP can be small. It cannot be broken, and it cannot be confusing. On that point, look at what 1.6 million bookings taught me: people forgive a missing feature, never an app that stutters or crashes.

Stack choices that buy speed

Technology does not make an MVP succeed, but it can delay one. My defaults are chosen for iteration speed.

One cross-platform codebase for iOS and Android. Building two separate native apps for an MVP means paying twice to learn once.

Managed services over custom infrastructure. Authentication, database, hosting: proven building blocks exist, cost a few euros per month, and eliminate weeks of work.

Simple, systematic design. A consistent component grid, clear hierarchy, no spectacular animation. Elegance can come later; clarity has to be there on day one.

AI where it accelerates. Content generation, smart search, support: features that used to take months can now be built in days, provided they are integrated with judgment, not for the brochure.

A realistic week-by-week plan

Here is what a six-week MVP looks like with me.

Week 1: scoping and design. The main flow gets pinned down, I design the key screens, and open questions get settled. By the end of the week, you can see your product.

Weeks 2–4: building the core. The main flow works end to end, connected to a real back-end. You test an intermediate version from week 3, on your phone rather than in a meeting room.

Week 5: finish and edge cases. Empty states, network errors, copy, onboarding. This is the week that turns a prototype into a product.

Week 6: release and measurement. Store submission, analytics in place, first users invited. The learning clock starts.

A wider scope pushes toward eight weeks. Beyond that, it is no longer an MVP. It is a full product in denial.

The mistakes founders repeat

Always the same ones, and they are expensive.

Building for the investor instead of the user. A pitch deck needs a vision; an MVP needs one satisfied user. The two feed each other, but they are not the same thing.

Waiting for perfection to launch. Every week of polish before launch is a week without learning. The version you are slightly embarrassed by today is the one you should have shipped.

Changing direction mid-build. A new idea every week destroys the timeline and the budget. Write ideas down, deliver the scope, then decide with data.

Neglecting measurement. An MVP without analytics is a boat without instruments. A few well-chosen events are enough: sign-up, core action, return the next day.

One senior builder vs a team: when each wins

For an MVP, one experienced person covering design, code and release is almost always faster than a team. Zero coordination, zero translation between designer and developer, decisions in hours instead of meetings. That is how I work, and my pricing reflects that light structure: from €5,000 for an MVP.

A team becomes the right call when the product demands several deep specialties in parallel (serious machine learning plus an app plus a complex back-office), or when the calendar forces massive parallel work. That is rarely the case at MVP stage. The right sequence: validate fast with one builder, then hire with evidence in hand.

Have an idea you want to test this season instead of next year? Tell me about your project: one 30-minute call, a scope, a fixed quote, and the clock starts.