Step 1: Define the problem — not the product
The biggest mistake founders make is starting with a feature list. Features are answers to a question you haven't asked yet. The question is: what problem are you solving, for whom, and why does it matter now?
Write one sentence that captures all three. "We help [specific person] do [specific thing] without [specific pain]." If you can't write that sentence, you're not ready to scope an MVP.
This isn't pedantry. The scope of your MVP — and therefore the time and money you spend — flows directly from the clarity of this statement. Vague problem definition leads to bloated MVPs that try to solve too many things and prove nothing.
Step 2: Identify your riskiest assumption
Every product is built on a set of assumptions. Some of them are obvious (people will sign up). Some of them are hidden (people will pay more than £10/month). Some of them are existential (people actually have the problem you think they have).
Your MVP should be designed to test the one assumption that, if wrong, would invalidate everything else. Not the safest assumption — the riskiest one.
Ask yourself: "What's the one thing we could discover in the next 60 days that would cause us to stop building entirely?" That's what your MVP should test.
Step 3: Scope ruthlessly
Once you know the problem and the assumption you're testing, write down every feature you could build. Then cut it in half. Then cut it in half again.
A useful exercise: for every feature on your list, ask "Would the product fail to test our core assumption without this?" If the answer is no, cut it. You can build it in v2. What you cannot do is get those weeks back.
A well-scoped MVP for most B2B SaaS products can be built in a single user journey: one type of user, one core flow, one outcome. That's not a limitation — it's a design principle.
What commonly stays in: the core user action, the minimum onboarding required to reach that action, and one output that shows the user the product worked.
What commonly comes out: admin dashboards (manual tools work fine at MVP scale), advanced settings, notification systems, social features, multi-tenancy, and anything described as "nice to have."
Step 4: Choose your build approach
There are three main options, and the right one depends on your product's complexity, your timeline, and your technical resources.
No-code (Bubble, Webflow, Glide) — fast and cheap, good for validating simple ideas, hits a ceiling quickly. Best for non-technical founders testing a linear workflow.
Custom development — takes longer and costs more, but produces a maintainable, scalable codebase. Essential if your product has complex logic, integrations, or regulatory requirements.
Hybrid — use no-code for the user-facing layer, custom code for the logic. A pragmatic middle ground for some product types.
The choice should be driven by the product requirements, not by budget alone. Building on no-code when your product genuinely needs custom development just means you'll pay twice — once to build it wrong, and once to build it right.
Step 5: Build in sprints, not one long waterfall
A waterfall build — where everything is designed, then everything is built, then everything is tested — is how projects balloon in time and cost. Changes accumulate in isolation, and by the time you get something to test, it's weeks out of date.
Sprints (typically two-week cycles) keep the build grounded. Each sprint has a defined goal, a set of features to complete, and a review at the end. You see working software every two weeks. You can adjust. You catch problems early, when they're cheap to fix.
At a high level, a 100-day MVP build looks something like this: two weeks of blueprint and scoping, eight weeks of sprint-based build, two weeks of testing and preparation for launch. The specific breakdown varies, but the principle holds — regular checkpoints, working software, ability to adjust.
Step 6: Define "done" before you start
This sounds obvious. It almost never happens.
"Done" should mean: a specific user can complete a specific flow and get a specific result, reliably, in a production environment, without someone from the development team in the room.
If your definition of done is vague ("the app works"), you'll spend the last three weeks of your build timeline arguing about whether features are ready. Write the acceptance criteria — even informally — at the start.
Step 7: Launch and measure the right metric
Your MVP is not finished when it launches. It's finished when it answers the question you built it to answer.
Choose one metric before launch and measure it ruthlessly. Not ten metrics — one. For a marketplace: do buyers complete their first transaction? For a SaaS: do users return within seven days? For a consumer app: does the core action get repeated within 48 hours?
Everything else is noise at this stage. You'll have time for dashboards and cohort analysis later. Right now you need a single number that tells you whether you built the right thing.
Where most builds go wrong
Step 1 and Step 3 cause the most failures.
Founders who skip proper problem definition end up building features that nobody asked for. Founders who refuse to cut scope end up with a product that takes twice as long to build, costs twice as much, and tests nothing clearly because it tries to do too much.
The builds we've seen fail most often aren't the ones that ran out of money mid-build. They're the ones that finished and discovered they'd built something nobody wanted — because they never asked the hard scoping questions at the start.
A note on "done enough"
There is a version of perfectionism that kills MVPs before they launch. If you're adding features because you're not comfortable showing users what you have, that's not product thinking — that's fear. An MVP should make you slightly uncomfortable. The gap between your vision and your v1 is the space where you learn.
Ship. Measure. Adjust.
If you're struggling with the scoping step — deciding what to cut — that's where we spend the first two weeks of every project at The MVP Studio. It's the most valuable part of the process, and it's available as a standalone engagement if you want to think it through before committing to a full build. Start the conversation here.