Olune

How to Scope an MVP (What to Build First)

Your MVP is not a small version of the product. It is the smallest thing that proves the riskiest assumption.

9 min read

The word "minimum" gets ignored and the word "viable" gets stretched until founders spend six months building a v1 nobody asked for. Scoping is the act of deciding what not to build, which is harder than deciding what to build. The goal of a first version is not to impress; it is to answer one question as fast as possible: will the people you targeted actually use this to get a job done, and value it enough to pay. This guide is a method for cutting an idea down to that core and shipping it in weeks, not quarters.

Name the one job before you name any features

Start with the job the customer is hiring your product to do, in their words, not yours. A founder who says "it's a dashboard with reports and integrations" has listed features. A founder who says "it tells a freelancer on Sunday night which invoices are overdue so they can chase them Monday" has named a job. The job is concrete, has a trigger, and has a moment of success you can build toward.

Write the job down as one sentence and pin it where you can see it. Every feature you are tempted to add gets one test: does this directly help the customer complete that exact job for the first time. If it is for the second use, the power user, or the edge case, it is not in the MVP. The single-job framing is the strongest defense you have against your own scope creep.

Find the riskiest assumption and aim the MVP at it

Every idea rests on assumptions, and they are not equally dangerous. List them: that the problem is painful enough, that people will switch from their current workaround, that you can actually deliver the result, that they will pay. Then rank by risk. The riskiest assumption is the one that, if wrong, kills the whole thing, and the one you currently have the least evidence for.

Scope the MVP to test that assumption first, not to be feature-complete. If the risk is "will anyone pay," your MVP might be a pre-sale page, not software. If the risk is "can this even be done well," your MVP might be you doing it by hand for five customers. Building the easy, fun parts while leaving the scary assumption untested is the most common way founders waste a year.

  • List your assumptions, then sort by "how dead are we if this is false."
  • Pick the single riskiest one with the least evidence.
  • Design the smallest thing that produces a clear yes or no on it.

Decide what to fake before you build it

The biggest scope savings come from realizing how much you can do manually or with duct tape. The customer cares about the result, not your architecture. A concierge MVP delivers the outcome by hand: you do the work behind a simple front, learn exactly what matters, and only automate what proves to be repetitive and valued. A Wizard of Oz MVP shows an automated-looking interface while you pull the levers behind the curtain.

Faking the hard parts is not cheating; it is the fastest way to learn what is worth automating. Manual fulfillment, a spreadsheet backend, a no-code form, a human answering what looks like a bot. Each one lets you ship in days and rip out only the pieces that earn their place. Automate later, once the demand and the workflow are proven.

  • Concierge: deliver the result by hand for your first users.
  • Wizard of Oz: automated-looking front, human-powered back.
  • No-code and spreadsheets behind a clean front beat a custom backend for v1.
  • Manual onboarding and support are features, not embarrassments, at the start.

Cut to the core path and protect it

Map the single happy path from a new user arriving to them reaching the moment the product worked, the aha moment. Write down every step on that path. That sequence is your MVP. Anything off that path (settings, profiles, alternate flows, the second feature) is a candidate for the cut list until proven necessary.

Be ruthless and specific about what gets cut, and keep a visible "later" list so cutting feels like deferring, not deleting. Polish, breadth, and configurability are where weeks disappear with no learning to show for it. One job, one path, done well enough that a real user reaches the payoff. That is the whole bar.

  • Build only the steps between arrival and the aha moment.
  • Send everything else to a written "later" list so you stop relitigating it.
  • Skip account settings, multiple themes, admin panels, and integrations until someone is paying and asking.

Set a deadline and a clear success bar

Scope expands to fill the time available, so cap the time. Give the MVP a hard deadline measured in weeks, and treat the date as fixed while the feature list flexes. If something will not fit, it gets cut, not crammed. A four-to-six week window forces the kind of decisions that a vague "when it's ready" never will.

Before you ship, decide what result counts as the assumption being validated. Pick a concrete behavior: a number of users completing the core job, a conversion to paid, a retention check a week later. Write it down first. If you hit it, you have earned the right to build more. If you miss it, you have saved yourself from building on a false floor, and you talk to users to decide whether to fix the product, the message, or the idea.

  • Fix the date, flex the scope. Cut, do not cram.
  • Define the pass bar (usage, payment, or retention) before launch.
  • Plan the conversation with users for both outcomes, pass or fail.

Key takeaways

  • An MVP is the smallest thing that tests your riskiest assumption, not a shrunken version of the full product.
  • Name the one job the customer hires the product to do, then cut every feature that doesn't serve that job's first use.
  • Fake the hard parts (concierge, Wizard of Oz, no-code) and only automate what proves valued and repetitive.
  • Fix a deadline in weeks, define the success bar in advance, and talk to users whether it passes or fails.

Put it to the test in 8 minutes.

Run your idea through Olune for a build-or-kill verdict on live Reddit signals, competitor maps, and keyword volume. Free to start.

Test your idea →

Keep reading

Common questions

How small is too small for an MVP?

It is too small when it can no longer let a real user complete the core job and reach the payoff. Cutting features is good; cutting the actual value is not. The test is simple: can one target customer use this to finish the one job and feel it worked. If yes, it is big enough.

Should I build the MVP with no-code or write real code?

For most first versions, use whatever gets you to real users fastest, and that is usually no-code, manual work, or a faked backend. Write custom code only for the part that is genuinely your differentiator and cannot be faked. You can always rebuild on a solid stack once demand is proven, but you can't get back the months spent building before validation.

What if customers ask for features I cut?

Note who asked and why, and add it to your visible "later" list rather than building it on the spot. A single request is a data point, not a mandate; build the feature when enough paying customers ask for the same thing. Early on, requests are most useful as signals about whether you nailed the core job, not as a backlog to clear.