Most founders asking how to scope an MVP already have the answer wrong before they start. They arrive with a feature list and try to trim it. Scoping by subtraction almost never works, because every feature on that list has a reason to exist and someone willing to defend it. Ninety days later you have a smaller version of the same bloated plan, still unshipped.
The method that works is the opposite: start from zero and earn your way up. One core loop, one user type, one metric. Everything else has to fight for a place, and most of it loses. This article walks through that method step by step, including exactly what to cut, what never to cut, and a one-page worksheet you can copy today.
Why 90 days is the right constraint
Ninety days is not arbitrary. It is short enough that the market cannot shift under you, long enough to build something real, and tight enough that scope decisions become forced rather than optional. A six month timeline lets you defer hard choices. A 90 day timeline makes you take them in week one, which is where they belong.
Maintaining more than 50 products over the years has taught us something uncomfortable about scope creep: it almost never arrives as one big feature. It arrives as a dozen small "while we're at it" additions, each individually reasonable, none individually rejected. The 90 day ceiling is your standing reason to say no to all of them without relitigating each one.
The method: one loop, one user, one metric
Scoping an MVP well means answering three questions and refusing to answer more.
One core loop
The core loop is the smallest repeatable action that delivers the product's value. For a marketplace, it might be: post a listing, get a response, complete a transaction. For an analytics tool: connect a source, see a report, act on it. Write your loop as a single sentence. If you need the word "and" more than twice, it is two products, and you are scoping the wrong one.
Everything you build in 90 days should make that loop complete, faster, or more trustworthy. A feature that does none of those three things is out, no matter how good it sounds.
One user type
Multi-sided products are the fastest way to double your scope invisibly. Two user types means two onboarding flows, two dashboards, two sets of edge cases, and two definitions of success. Pick the side whose behavior you understand least, build for them, and simulate the other side manually. A founder answering marketplace requests by hand for a month is not a hack. It is research you would otherwise pay for.
One metric
Choose the single number that proves the loop works. Loop completions per week is usually a better choice than signups, because signups measure curiosity and completions measure value. Write the metric down before you build anything, along with the number that would convince you to keep going. Deciding what success looks like after launch is how teams talk themselves into anything.
What to cut without guilt
These are the categories that feel essential during planning and turn out to be almost weightless at launch.
- Roles and permissions. An MVP has two roles: user and you. Granular permission systems are among the most expensive things to build and the least likely to matter before you have teams as customers. Ship with a flat model and a manual override.
- Settings pages. Every setting is a decision you refused to make. Pick sensible defaults, hardcode them, and change them by hand for the rare user who asks. If ten users ask for the same toggle, that is your post-launch roadmap writing itself.
- Admin polish. Your internal admin panel can be ugly, slow, and half database client. You are its only user and you will forgive it. Founders routinely spend two of their thirteen weeks making tools nobody outside the company will ever see look presentable.
- Notification variety. One channel, usually email, one template style. Preference centers, digests, and in-app notification feeds all wait.
- Native mobile apps. Unless the loop is physically impossible in a browser, a responsive web app buys you months.
Notice the pattern: everything on this list can be faked with human effort or a default value. That is the test for whether something belongs in an MVP. If a person can do it manually for the first hundred users, software should not do it yet.
What never to cut
Three things do not follow the fake-it rule, because retrofitting them is dramatically more expensive than building them once.
Authentication. Do not invent your own. Use a proven library or managed service, get password reset and session handling right, and move on. A homegrown auth shortcut is a security incident on a delay timer, and cleaning one up mid-growth will cost you far more than the week you saved.
Payments. If money moves through your product, that path gets full engineering attention from day one: idempotent charge handling, clear refund logic, and honest failure states. Users forgive a plain interface. They do not forgive being charged twice.
Data integrity. This is the least glamorous item and the one we defend hardest. Our average client relationship runs about five years, which means we live with the databases we design at MVP stage for a very long time. Proper constraints, transactions around multi-step writes, and a schema that reflects reality are nearly free in week one and brutally expensive in year two. Your MVP's data model is the one part of the codebase most likely to survive every rewrite.
The scoping worksheet
Put this on one page and make it the only planning document for the build. If a request is not on the page, it is not in the 90 days.
- User: one sentence naming who this is for and the situation they are in.
- Loop: one sentence describing the repeatable action that delivers value, with at most two "and"s.
- Metric: the single number that proves the loop works, plus the threshold that means "keep going".
- In scope: the five to eight capabilities the loop cannot function without. If you list more than eight, your loop sentence is hiding a second product.
- Explicitly out: the ten things you are tempted to build and are choosing not to. Writing them down matters, because a cut that lives only in someone's head gets rebuilt in week six.
- Manual for now: the operations a human will perform behind the scenes at launch.
- Never compromised: auth approach, payment provider, and the three or four data invariants that must always hold.
- Ship date: a calendar date, not a sprint number.
Review the page weekly. Any proposed change must displace something already on it. That single rule does more to protect a 90 day timeline than any project management tool.
When the 90 days end
Shipping is not the finish line, it is the start of the measurement window. Give the metric four to six weeks of real usage before judging it, resist adding features while you wait, and spend that time talking to the users who completed the loop and the ones who abandoned it. The gap between those two groups is your next scope document.
If you want a second pair of senior eyes on a scope before you commit a quarter to it, that is a conversation we have often. You can reach ETREXIO here.
Frequently asked questions
How many features should an MVP have?
Count capabilities, not features: five to eight things the core loop cannot function without is a healthy ceiling. If your list runs longer, the loop definition is probably hiding two products, and splitting them will get you to market faster than building both halfway.
How long should it take to build an MVP?
Ninety days is a strong default for a scoped MVP with one core loop and one user type. Shorter timelines usually mean a prototype rather than a product, and longer ones invite scope creep, since every extra month weakens the pressure that forces real prioritization.
What should you not include in an MVP?
Skip role and permission systems, settings pages, polished admin tools, notification preferences, and native mobile apps. Each can be replaced by a sensible default or manual human effort at launch, and real usage will tell you which ones actually deserve engineering time afterward.
What is the biggest mistake when scoping an MVP?
Scoping by subtraction: starting from a full feature list and trimming it. Every item has a defender, so the cuts stay shallow. Starting from zero with one loop, one user, and one metric, then forcing additions to justify themselves, produces a genuinely shippable scope.
