You have a list of thirty features, a launch date and a growing suspicion that not all of them belong in version one. Open the list now and write one sentence at the top: the single job a customer will pay you to do. Everything below is a way to test each feature against that sentence.
This is the scoping step behind the SaaS MVP development guide. The guide covers what an MVP is and how long it takes; this article covers the part most teams get wrong, which is deciding what goes into it. You get a scoring model, a comparison with RICE and MoSCoW, and two lists: features to cut and features you should not cut.
Why do most SaaS MVPs end up with too many features?
MVPs bloat because founders add a feature for every imagined objection and list what the product has instead of the job it does, so even a trimmed list describes a small product, not a minimum one.
The first cause is fear. You picture a prospect asking "does it do X?" and you do not want to say no, so X goes on the list. Multiply that by every imagined objection and the MVP quietly becomes the full product with a launch date attached.
The second cause is feature thinking instead of workflow thinking. A dashboard, exports, role management and an analytics tab are things the product has. Viable means a real customer can finish one job end to end with nothing else on screen. The complete SaaS MVP guide covers that reframing in depth.
The cost of overload is more than time. Every extra feature is a surface that must be designed, built, tested and maintained for the life of the product. The evidence on why products fail points the same way: CB Insights analysed 431 venture-backed shutdowns since 2023 and found poor product-market fit cited in 43% of them. This suggests that the risk to manage first is building the wrong thing, not building too little of the right thing, which is an argument for a smaller first release that reaches customers sooner. That reading is my inference from the data, not a finding of the study.
What is the one-loop rule for MVP feature prioritization?
The one-loop rule says you write the core workflow as a single sentence, and only features that workflow cannot run without may enter the MVP. If you cannot write the sentence, you are holding more than one product.
Here is how the sentence looks for products in my own portfolio. These are my framings of what each product does, based on its case study, not quotes from the clients.
- Callidus, a multi-tenant SaaS for UK aesthetic clinics built with React, Firebase and Stripe Connect: a clinic schedules a patient, records consent and treatment, and collects a deposit through its own Stripe account.
- BookBed, a property-management system built with Flutter, Firebase and Stripe that runs on iOS, Android, Web, macOS, Linux and Windows: an owner keeps availability correct across the booking channels a unit is listed on.
- Pizzeria Bestek, a four-language ordering app built with React and Supabase for a single-location pizzeria: a customer orders in their own language and the owner confirms or declines by email.
With the sentence written, each candidate feature gets one question: does the loop physically break without it? Not "is it nice" and not "would it impress someone". A yes-or-no question is much harder to argue around than "should we add this?". For the calendar version of this exercise, the 12-week realistic MVP roadmap places the surviving features into weekly milestones.
How do you score features in an MVP prioritization matrix?
Score each surviving feature on loop dependency, build cost and retrofit pain, then build first whatever scores high on dependency and high on retrofit pain, regardless of how exciting the alternatives are.
- Loop dependency. Does the core loop break without it? High means the loop fails. Low means the loop limps but runs.
- Build cost. How much engineering time does the thinnest acceptable version take? Be honest about thin, not dream.
- Retrofit pain. How expensive is it to add this after launch, with real customer data in the system?
Retrofit pain is the axis most teams skip, and it decides build order. Customers never ask for "per-tenant data isolation", but if you launch without it and need it later, you are reshaping a data model with live data inside it. Firebase's documentation describes Firestore Security Rules as access control and data validation, and that is the layer where tenant isolation lives on a Firebase stack. The Callidus case study reports 100% Firestore rules coverage in a system where each clinic is a strictly isolated tenant. The trade-offs against a Postgres row-level-security model are in the multi-tenant SaaS architecture guide.
Reading the scores: high dependency plus high retrofit pain means build first. High dependency plus low retrofit pain means build during the core loop. Low dependency means defer, however cheap it looks, because cheap features still add surface to maintain.
How does this compare with RICE and MoSCoW?
| Method | What it scores | Where it fits | Weak spot for an MVP |
|---|---|---|---|
| One-loop test plus three axes | Loop dependency, build cost, retrofit pain | Pre-launch, no usage data | Needs an honest loop sentence |
| RICE | Reach, impact, confidence, effort | A backlog with usage data | Reach and impact are guesses before launch |
| MoSCoW | Must, should, could, won't | Agreeing a release scope with stakeholders | Without a definition of "must", the category can absorb everything |
Intercom defines RICE as the four factors reach, impact, confidence and effort, calculated as (Reach × Impact × Confidence) ÷ Effort. ProductPlan describes MoSCoW as Must-have, Should-have, Could-have and Won't-have, created by Dai Clegg while at Oracle. Both are sound methods. Before launch you have no real reach or impact numbers, which is why I start with the one-loop test and switch to RICE once customers produce signal. You can also run MoSCoW after the loop test as a stakeholder conversation, using the loop as the definition of "must".
Which features should you cut and which should you keep?
Cut anything you can add cheaply later, and keep anything that is cheap to build now but ruinous to retrofit once customers and data exist. Analytics, integrations and extra roles are cuttable; tenancy, billing, authentication and the core data model are not.
Which features should you cut from the MVP?
Default to cutting these, and let a paying customer pull them back in.
- Analytics and reporting dashboards. Your first customers want the job done, not charts about the job. Ship a raw data export and add visualisation when someone pays for it.
- Third-party integrations. A full integration is weeks of work plus ongoing maintenance against someone else's API. A CSV import or export covers the same need for the first customers.
- Extra user roles. Permission systems are deceptively expensive. One role is enough until a customer genuinely needs to invite a colleague. Callidus ended up with six roles, and its case study notes the codebase is built around role helpers to stop access checks drifting, which gives a sense of the cost you take on.
- Settings and customisation screens. Every toggle is a code path you maintain. Hard-code the sensible default.
- Extra platforms. BookBed reaches six platforms from one Flutter codebase, but a web app is enough to test most loops. Platform coverage is a scaling decision, not a validation step.
Replace each cut feature with a manual step, a spreadsheet or an email until customer money says to automate it. Manual work at small scale teaches you what to build. If the scope is small enough that code itself is optional, Webflow and Zapier for a SaaS MVP shows where the no-code line sits.
Which features should you never cut?
These feel like later work but are day-one decisions, because adding them after launch is expensive.
- Tenancy and data isolation. Decide how one customer's data stays separate from another's before feature work starts.
- Billing. A paying customer is the only proof that survives contact with reality. Callidus uses Stripe Connect Standard so each clinic takes payments into its own account. BookBed has Stripe subscriptions wired in but not yet activated for paid traffic, which is a deliberate middle path: the plumbing exists, the switch is off. Stripe's pricing page lists 2.9% + 30¢ per successful domestic card transaction on standard pricing, checked in September 2026, so the cost of accepting money is visible before you build.
- Authentication. Auth touches every request, and choosing it late means re-threading identity through code you already wrote.
- The data model behind the loop. Renaming and reshaping core tables once you hold customer data is slow and risky.
Scope discipline is how a small team ships on a short clock. Callidus was built solo in roughly ten weeks and replaced an inherited FlutterFlow attempt with about 200 unresolved errors, and my published pricing puts SaaS MVP engagements at 6 to 12 weeks. Those numbers describe my projects, not a guarantee for yours.
Take your list from the top of this page and write down, for each feature, yes or no to "does the loop break without it?". Send me the ones that survive at info@duskolicanin.com and I will tell you which I would cut next.