Scope an MVP you can actually ship.
Pick your product type, sort a realistic feature library into Must, Should, Could and Won’t, and re-rate what your users value. The planner shows how many weeks the first release takes with a traditional team and with an AI-native one, the budget, a risk score and the features worth deferring.
Decide what makes the first release
Start from a preset, sort each feature into Must, Should, Could or Won't, and re-rate its value. The plan updates as you go.
- Traditional9 wks · $45,000
- AI-assisted8 wks · $40,000
- AI-native7 wks · $33,000
- Core workflow customers pay for~130h
- Sign-up, login and teams~18h
- Email notifications~9h
- Scope looks disciplined: fits the 12-week target with about 5 weeks to spare and no low-value, high-effort features.
- Should: Guided onboarding (~54h saved)
- Should: Subscriptions and billing (~90h saved)
- Should: First key integration (e.g. CRM) (~83h saved)
- Could: Analytics dashboard (~90h saved)
- Could: Roles and permissions (~75h saved)
- Could: CSV export and reports (~36h saved)
- Could: AI assistant inside the product (~120h saved)
- Could: Internal admin panel (~60h saved)
- Won't: Enterprise SSO (~54h saved)
- Won't: Audit log (~42h saved)
- Won't: Public API (~90h saved)
- 3 features in scope, which is a healthy size for a first release.
- An AI-native team saves about 2 weeks against a traditional team on this scope under these assumptions.
- The saving is smallest on novel, high-risk features (AI features, offline, complex integrations), so those still set the pace.
- AI-generated code on an MVP still needs senior review, or you trade speed now for a rewrite later.
Assumes a short discovery phase, one launch buffer week and 32 productive hours per engineer per week. AI multipliers are conservative assumptions, not guarantees.
Indicative only. We will send the inputs above with your message so a senior engineer can sanity-check them.
From feature wishlist to a scoped first release
The model is deliberately simple enough to explain, and every number it uses is a named assumption rather than a black box.
Load a feature library
InputEach product type comes with 13 or 14 candidate features, each carrying a typical effort in engineering hours, a default user value, a delivery risk rating and a flag for whether it can be bought as a service.
Sort with MoSCoW
PrioritiseMust-haves are always in scope. Should-haves join only if you switch them on. Could and Won’t features form the cut list, with the hours they save shown next to each one.
Apply delivery assumptions
ModelEffort is adjusted for buying commodity features, for your launch goal (a public launch needs more hardening than a demand test) and for how the team uses AI. AI savings are scaled per feature, so a login screen gains more than a novel AI workflow.
Schedule and stress-test
OutputHours become weeks using your team size, with a small coordination loss per extra engineer. If you miss your target date, the planner defers the lowest value-per-effort features until the plan fits, and never touches anything you rated 5.
An MVP is a question, not a small product.
The purpose of a minimum viable product is to answer one risky question with real users: will they sign up, will they pay, will they come back? Scope follows from that question. If a feature does not help you answer it, it belongs in the Could or Won’t column, however obvious it feels in a planning meeting.
The most common scoping mistake we see is treating the MVP as version one of the finished product, with roles, dashboards, settings and edge cases included from day one. Every one of those features is reasonable on its own. Together they push the first real user feedback out by months, and by the time it arrives the budget has gone.
AI-native development has made building cheaper and faster, which is a reason to test ideas sooner, not a reason to build more before testing. A lean team using coding agents can often ship a disciplined MVP in weeks rather than months. The discipline about what not to build is still the part that decides whether the MVP teaches you anything.
What each MoSCoW bucket should mean for a first release
MoSCoW only works when the buckets have strict definitions. These are the tests we apply when prioritising an MVP feature list with founders.
| The test | Typical examples | What happens to it | |
|---|---|---|---|
| Must have | Without it, the core question cannot be answered | The core workflow, sign-up, the one integration customers insist on | Built for launch, kept as simple as possible |
| Should have | Painful to lack, but a workaround exists | Billing (invoice manually), onboarding (do it on a call) | Next iteration, or included if the timeline allows |
| Could have | Nice to have, nobody will leave without it | Dashboards, exports, social sharing, AI suggestions | Backlog, revisited with usage data |
| Won’t have (yet) | Only matters at a scale or stage you have not reached | Enterprise SSO, public API, fine-tuned models, offline mode | Written down explicitly so it stops coming back |
| AI features | Is AI the product, or a feature on top of it? | RAG answers for an AI product; a chatbot bolted onto a SaaS | Must if it is the product, usually Could if it is not |
Effort figures in the planner are indicative for a lean first version and assume a competent, experienced team. Real estimates depend on the detail behind each feature.
Getting honest results from the planner
Rate value from the user’s side, not yours
Ask whether an early customer would notice the feature missing, not whether you would like to have built it.
Fake it before you build it
Anything a founder can do by hand for the first twenty customers (approvals, onboarding, reports) can usually move down a bucket.
Keep buying commodity features switched on
Login, payments, email and analytics are solved problems. Building them yourself rarely helps you learn anything about your market.
Treat the risk score as a conversation starter
A high score usually means several novel features in one release. Splitting them across iterations reduces the chance of one of them stalling everything.
Plan for AI-generated code to be reviewed
The AI-native timeline assumes senior engineers review what agents produce. Skipping that review is how fast prototypes turn into expensive rewrites.
Questions we often hear
How do you decide the scope of an MVP?
Start with the single riskiest assumption about your business and include only the features needed to test it with real users. List every other idea explicitly as Should, Could or Won’t, so the team has a shared record of what was deliberately left out. Then check the result against your budget and launch date, and cut again if it does not fit.
What is the MoSCoW method of prioritisation?
MoSCoW sorts requirements into Must have, Should have, Could have and Won’t have (this time). It is popular for MVPs because it forces a conversation about what is truly essential. It only works if Must has a strict definition, such as “the product cannot answer its core question without it”.
How many features should an MVP have?
There is no fixed number, but most well-scoped MVPs have one core workflow plus a small set of supporting features such as sign-up, notifications and basic analytics. If your Must list runs past eight or nine items, it is worth asking which of them could be handled manually for the first customers.
How long does it take to build an MVP?
A focused MVP commonly takes 6 to 12 weeks with a small experienced team, and longer for marketplaces, regulated products or anything with several complex integrations. Scope matters more than team size: adding engineers to an oversized MVP rarely brings the date forward as much as cutting features does.
Does AI make MVP development faster?
Usually, yes. AI-native teams use coding agents for standard screens, integrations, tests and documentation, so the same scope typically needs fewer engineer-hours. The gains are smaller on novel logic, AI features themselves and product decisions, and the code still needs senior review, which is why the planner applies conservative, per-feature assumptions rather than one big multiplier.
Related reading and tools
Not sure what to cut?
Send us your plan from the scope planner. A senior engineer will look at your Must list, challenge what does not need to be in the first release and give you an honest view of the timeline with an AI-native team.
Working with companies globally · Response within 24 hours