MVP Development Process: A Founder’s Playbook

You won’t find most MVPs failing in the code. They are dead months before that, in the mind of someone who has mistaken “minimum” for a shrunken version of all they plan to build one day. The numbers back this up: CB Insights’ post-mortems attribute some 35% of startup deaths to a simple lack of market need. A McKinsey and Oxford study is even more blunt on large software projects that skip early validation, showing them to run 45% over budget while producing 56% less value. An MVP is there to ensure you don’t end up on the wrong side of those figures.

Consider this a guide for the idea man or woman who is feeling the budget squeeze and suspects there is a way to be cheaper and sharper than a twelve-month build. There is. The technology is never the hard part. It is the discipline to decide what you must learn first and not put anything else in front of your users until you have.

What an MVP Actually Is

Put simply, an MVP is the least you can do to test a belief you hold about a user and his problem. Eric Ries called it the quickest route to validated learning and if you read the Wikipedia definition you will see it is still spot on: the product version that yields the most learning for the team with the minimum of fuss.

But “learning” is the word teams tend to gloss over. Don’t think of an MVP as a small product. It is an experiment with a working face. If you put one out there and can’t say “here is something we didn’t know before,” then you haven’t shipped an MVP. You’ve put an apologetic label on a v1.

Prototype, POC, MVP: the differences that matter

There is no reason to use these terms as if they were the same.

• Prototype: A sketch or clickable design. No backend, no real users. Good for testing flow.
• Proof of concept: An internal exercise to prove technical feasibility. Some of it may be faked behind the scenes.
• MVP: Real usage by real users to solve a real problem. It works from start to finish for a single task and is judged on behaviour, not how complete it is.
• Beta: Nearly feature-complete. You use it to harden the product, not to make the call on whether to continue.

For a plain English breakdown of the framing before you commit to scope, have a look at our Minimum Viable Product Guide.

The Process, End to End

No one with any credibility will argue with the process. Whether you are doing Lean Startup or agile delivery, the pattern is the same: discover, scope, design, build in sprints, instrument and launch in stages, then iterate. Where you might see disagreement is on the polish. For a SaaS MVP of any substance, eight to fourteen weeks is the norm; six to twenty is the outer limit. Go past six months and you have a scope issue, not a complex one.

Harvard Business School puts it well in their summary on MVP development: treat the work as a series of small experiments where you test one variable, not as a race to a finish line.

Step 1: Write the hypothesis before you write anything else

Before you get to wireframes or pick a stack, put a sentence like this on paper:

We believe [specific persona] has [specific painful problem] and will [sign up, pay, return, refer] if we offer [specific solution].

Make every feature in your backlog earn its keep by passing through that filter. If it doesn’t help you test the statement, it has no place in the MVP. It may have its uses down the road, but not now.

Step 2: Discovery, with real people

What separates the successful MVPs is that the team spoke to users before writing production code. Do 20 or 30 interviews with your target segment. If 70 percent of them put the same problem into similar words, you have your signal. If not, your hypothesis is flawed and building won’t remedy it.

Don’t ask “would you use this?” – it is the worst question in the book. Look for behaviour. Time, money or an email address given up willingly are the useful signals. A waitlist on a landing page, a pre-order, a concierge service to manually handle things before the backend is even in place. We go into the full playbook in our product discovery guide.

Step 3: Cut scope until it hurts

Your MVP should be a single journey for a narrow group. Think of Dropbox and their video to gauge demand, or the Uber of old with a handful of cars in one city and GPS. Or Airbnb’s founders taking photos of San Francisco apartments for a conference. One path, one decision.

Be honest with your MoSCoW list. Must-Haves only. Park the rest. And write down the Won’t-Haves in black and white; you will want to show that to a stakeholder in week six when he asks why you can’t just add one more thing.

Bucket	Rule
Must have	Without it, the core action cannot be completed.
Should have	Helpful, but the experiment runs without it.
Could have	Nice. Park it.
Won’t have yet	Documented and dated. This is your scope shield.

Step 4: Pick a build path that matches the risk

When you come to the build, the question isn’t which framework to use but what risk you are managing. Is it demand? Then a no-code or concierge approach will give you an answer quicker than custom work. Is it unique logic or data you will have to own in the end? Custom code is the cheaper option.

As for the stack, what you are seeing in practitioner circles for 2025–2026 is fairly uniform: Next.js and Tailwind up front, Supabase or Postgres for the data, Stripe to take the money, Vercel to deploy and Sentry to watch over it. You have something type-safe and low on maintenance that can make it to production with no need for a rebuild. Then there is the matter of AI tooling – ChatGPT on the PRD, Cursor for your code, Lovable or its ilk for UI scaffolding – which in truth will compress your build time. You will see independent figures put the productivity bump at 20 or 30 per cent; the vendors will tell you it is much more, so take their word for it with the appropriate grain of salt.

But don’t expect AI to do the heavy lifting on discovery or organisational alignment, nor will it speed up post-launch iteration. The bottleneck is still there, it has just moved.

Step 5: Build in short cycles with founder involvement

Unless you are in a heavily regulated field, an MVP is going to be delivered in one- or two-week sprints. Atlassian’s take on the minimum viable product process lays out the usual rhythm: define the problem, prioritise, prototype fast, build lean and stage the launch.

Done right, you are involved in this on a weekly basis. We are talking about the nitty-gritty of copy, onboarding, edge cases, who has what permissions and how payments behave. Those are decisions to be made, not left as implementation details. Should your build partner go dark for a month and come back with a demo, consider it a warning sign rather than a milestone.

Step 6: Instrument before you launch, not after

Set your success metrics before the product is live. If you don’t, you’ll be wasting the first month after launch having a row over whether it was any good. For most MVPs the only numbers worth looking at are activation (did the new user do the core thing?), churn and retention at day 1, 7 and 30. Let the page views and downloads be noise. We have a read on the post-launch side of things in how to measure product market fit.

Put your decision gates in writing. “By week 12 if day-7 retention is under X we pivot.” Or “Y paying accounts and we put money into onboarding automation.” It is the difference between teams that learn and those that argue.

Where MVPs Actually Die: the Uncanny Valley After Launch

The trouble spot in 2025-26 won’t be the build. It will be the weeks following launch when the product is functional but clunky, the team is running on fumes and users aren’t sticking around. On X and Reddit they are calling it the uncanny valley of MVPs. The ones that win will put in two or three more cycles to close the gap: better transitions, copy that lands, and a couple of moments that are a pleasure to use.

Make room for that in your budget. A seasoned team will factor in another 20 to 40% of effort in the opening months. If your cost model says the job is done at launch, the product will die a quiet death.

With AI products the failure mode is altogether worse. Some 80% of prototypes never make it to production, and rarely is it down to the model’s accuracy. More often it is compliance, security, integration or the fact there is no business owner with a KPI to answer to. If you are putting together an AI MVP, get security and ops in the room early and nail down the metric (“cut call handling by 20%”) before you even choose the model.

What This Looks Like When It Works

Take Workform, an AI MVP we put together with a project management consultant. We built it starting from the idea of an assistant that would do everything for a PM. Discovery whittled that down to something far more concrete: an assistant that takes in context from Slack, Asana, email and meetings to keep a project in motion. The reframing was the hard part; the build followed.

Or look at the other end of the spectrum with CinemaAssist, an online ticketing MVP for an indie cinema in San Jose. You could be tempted to build the kind of platform you see in every multiplex, but the question for the MVP was simpler: can this theatre sell tickets with proper payment settlement before the customer has left home? One segment, one journey, one decision point.

In both cases the pattern is the same. The first version does one thing well enough for one user so you can decide if the rest of the roadmap is worth the trouble.

The Mistakes That Usually Make This More Expensive

Across the years and types of product the ways to fail are all too familiar.

• Scope creep because of what investors want. They want to see demand, not feature parity with the finished article.
• Dogfooding as validation. Your team is not the market; they have different patience and incentives.
• Over-engineering. Microservices and exotic frameworks are of no use to your first 50 users.
• Chasing a broad TAM. You end up with a weak value proposition. Pick a segment.
• Thinking the finish line is at launch. The MVP becomes a learning tool the moment users show up.
• Founder ego. Don’t let the iteration cycle stall because you take criticism of the MVP personally. It is a test of the idea, not you.

As for cost, a genuine discovery phase runs $5,000 to $15,000 and the build anywhere from $20,000 to $250,000 depending on how complex it gets. Our MVP development cost guide goes into what moves the needle. For SaaS products in particular, the SaaS MVP development guide is more specific on the platform and pricing side.

How to Decide What to Do This Week

Don’t put in for a build quote if your concept is still hazy. Put pen to paper and on a single page make note of four items: who the user is, the problem that aches for a solution, the most basic thing they can do with your product to get some value from it, and what would tell you the idea has legs. Should any of those be indistinct, you need to do some discovery work before you think about engineering. We have put together a more down-to-earth take on this exercise in our piece on how to validate the business idea prior to building anything.

Once you have those four points in focus, move on to a prototype and have 20 or 30 genuine conversations with folks in your segment. A strong, consistent signal from them means it is time to be ruthless with the scope. Time-box the project at four to twelve weeks and only put in the work that puts the hypothesis to the test. Instrument it ahead of launch and factor two or three rounds of iteration into your budget from the start.

When the product has stabilised and you are ready to put out a launch to an audience beyond your own, there is no need for the expense of a full PR campaign; a press release distribution service will do the job of extending your reach.

In the end, what counts in an MVP is not the technical side but your judgment as to what to omit. That is the heart of Refact’s product design and discovery process. The decisions made early on are what determine if the rest of the project justifies its cost, which is why we back our discovery phase with a money-back guarantee.