How to scope an MVP you can launch in 14 days
A practical way to cut a product idea down to the one thing worth proving first: the assumption, the core workflow, and a written list of everything that waits.
By Ali Sufyan, founder of MVP Ninja
· 2 min read
Most MVPs that run late weren't built slowly. They were scoped too big. The fix isn't to work faster; it's to decide, before anything is built, what the first version has to prove and what it doesn't.
This is the method we use on every build. You can do it on a single sheet of paper.
1. Write down the one assumption
Every product idea rests on a belief that might be wrong. "Clinics will let patients book themselves." "Reps will trust AI research if they can see the sources." Write yours as one sentence. If you can't, the idea isn't ready to build yet, and that's worth knowing now.
2. Find the workflow that tests it
Ask what a real person would have to do, start to finish, for you to learn whether the assumption holds. That path is your core workflow. It usually fits on three to five screens. Everything the MVP includes should serve it.
3. Cut everything else, in writing
Settings pages, a second user type, the native app, reporting, integrations nobody has asked for yet: list them, then move each one to a column called "Later". Writing it down matters. It turns "we forgot that" into "we chose that", and it makes version two easy to plan and price.
Two things are almost never worth cutting: whatever your first users touch every day, and the basics that keep their data safe.
4. Match the scope to a length
- One workflow and one kind of user fits a week.
- Up to three workflows, with an admin view, fits two weeks.
- Several roles, an AI agent that takes actions, or a native mobile app needs three.
If your list doesn't fit three weeks, it isn't an MVP yet. Go back to step three. You can try this on a sample idea with the scope cutter on our homepage, which moves features across the cut and shows the length change.
5. Agree how new ideas are handled
New ideas will come up during the build. That's a good sign. Put them on the change list, not into the current build, and nothing gets added to the scope or the price without your approval. That one rule is what makes a fixed date and a fixed price possible.
If you'd rather not do this alone, it's exactly what our five-minute brief and scoping call are for. You get the written scope and fixed price before you pay anything.