To prioritize SaaS MVP features, name the single workflow your first customers will pay for, then keep only the features that workflow cannot run without. Score every other idea against that one loop and push anything that merely supports or decorates it into a later version. The output is not a wish list ranked by excitement — it is a short, defensible list where each feature can explain why launch fails without it.
This is the scoping discipline behind the SaaS MVP development guide. The guide explains what an MVP is and how long it takes to build; this article is the part most people get wrong — deciding what actually goes in it. Below is the exact framework I use, including a scoring model, the features people wrongly cut, and the ones they wrongly keep.
Key takeaways
- Prioritize against one core loop written as a single sentence. If a feature does not serve that loop, it is not an MVP feature.
- Score each feature on three axes — does the loop break without it, how much does it cost to build, and how painful is it to retrofit later. Retrofit pain is the axis people ignore.
- Multi-tenancy, billing, and auth are MVP-day features even though customers never "ask" for them, because retrofitting them after launch is the most expensive rework there is.
- Reporting, integrations, settings pages, and second user roles are usually post-MVP. Replace them with a manual step or a CSV until a paying customer demands more.
- Build the thinnest version of every feature that survives. An email beats a notification center; a CSV upload beats a full integration.
- A scope that passes this filter ships in roughly 6 to 12 weeks solo. A scope that fails it is why MVPs slip into quarters.
Why do most SaaS MVPs include too many features?
The overload almost never comes from laziness. It comes from good intentions and fear. You imagine the demo where a prospect asks "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 source is feature thinking instead of workflow thinking. You list what the product "has" — a dashboard, exports, role management, an analytics tab — and trim that list down. But a trimmed feature list is still a small product, not a minimum viable one. Viable means a real customer can finish the one job they would pay for, end to end, with nothing else on screen. That reframing is the whole game, and it is covered in depth in the complete SaaS MVP guide.
The practical cost of overload is not just time. Every extra feature is a surface that has to be designed, built, tested, and then maintained for the life of the product. A feature you ship to win one hypothetical demo is a feature you debug for years. Cutting it is the highest-impact decision in the whole build.
What is the one-loop rule for SaaS MVP scoping?
The rule: write your core loop as a single sentence, and let that sentence be the only thing that grants a feature entry into the MVP. If you cannot describe the loop in one sentence, you are holding more than one product and you need to choose.
Real examples from products I have built:
- Callidus, a clinic SaaS built with React, TypeScript, and Firebase: "A clinic books a patient, manages the appointment, and bills for it." Everything in the MVP orbited that sentence.
- BookBed, a booking SaaS built with Flutter and Firebase: "A property manager keeps availability correct across the channels a unit is listed on." The product now runs on six OS platforms — iOS, Android, Web, macOS, Linux, and Windows — from one codebase, but the loop came first.
- Pizzeria Bestek, a four-language ordering app built with React and Supabase: "A customer browses the menu in their language and places an order the kitchen sees in real time."
Once the sentence exists, every feature gets one question: does the loop physically break without you? Not "is this nice," not "would this impress someone" — does the customer fail to complete the job if this is missing. That is a yes/no question, and yes/no questions are much harder to argue your way around than "should we add this." The longer, calendar-anchored version of this exercise lives in the 12-week realistic SaaS MVP roadmap, which slots the surviving features into weekly milestones.
How do you score and rank MVP features?
Once features pass or fail the one-loop test, the survivors still need ordering, because you cannot build them all in week one. Score each surviving feature on three axes, low to high:
- Loop dependency — does the core loop break without this feature? (High = the loop fails; Low = the loop limps but runs.)
- Build cost — how much engineering time does the thinnest acceptable version take? (Be honest; the thinnest version, not the dream version.)
- Retrofit pain — how expensive is it to add this after launch, with real customer data already in the system?
The third axis is the one almost everyone skips, and it is the one that decides build order. A feature with high loop dependency and high retrofit pain goes first, no matter how tempting it is to start with something visual and fun. Multi-tenancy is the textbook case: customers never ask for "per-tenant data isolation," but if you launch without it and then need it, you are rebuilding your data model with live data in it — the most expensive rework that exists.
That is exactly why Callidus shipped with per-tenant Firestore security rules from the first commit, scoped by JWT tenantId claims so one clinic could never read another clinic's patients. It was invisible to the buyer and load-bearing for the build. The trade-offs between that approach and a Postgres row-level-security model are laid out in the multi-tenant SaaS architecture guide — choosing the wrong isolation model is the most painful retrofit on the list.
A simple way to read the scores: high dependency plus high retrofit pain equals build first. High dependency plus low retrofit pain equals build during the core loop. Low dependency equals defer, regardless of how cheap it looks.
Which features should you cut from a SaaS MVP?
These are the features that feel essential and almost never are. Default to cutting them 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 the raw data export and add visualization when someone pays for it.
- Third-party integrations. A full integration is weeks of work and ongoing maintenance against someone else's API. A CSV import or export covers the same need for the first ten customers.
- Second and third user roles. Admin-versus-member permission systems are deceptively expensive. Most MVPs work fine with one role until a customer genuinely needs to invite a teammate.
- Settings and customization screens. Every toggle is a code path you maintain forever. Hard-code the sensible default and expose settings only when a real request forces it.
- A native mobile app, when web works. Cross-platform reach is real, but it is rarely the thing standing between you and the first sale. BookBed reaches six platforms from one Flutter codebase, yet the MVP still started by proving the loop, not by chasing platform coverage.
The pattern is the same every time: replace the feature with a manual step, a spreadsheet, or an email until a customer's money tells you to automate it. Manual work at small scale is a feature, because it teaches you exactly what to build. If your scope is small enough that even the code is optional, using Webflow and Zapier for a SaaS MVP shows where the no-code line sits.
Which features should you never cut?
The inverse list matters just as much. A handful of features feel like "later" work but are actually MVP-day decisions, because the cost of adding them after launch is brutal:
- Tenancy / data isolation. Decide on day one how one customer's data is kept separate from another's. Retrofitting isolation onto live data is the single most expensive thing on this page. Callidus baked it in via per-tenant Firestore rules before any feature work.
- Billing. Charge from day one. A paying customer is the only proof that survives contact with reality, and wiring Stripe — subscriptions, webhooks, the money side — early avoids a painful re-architecture. Callidus used Stripe Connect Standard so each clinic could take its own payments.
- Authentication. Auth touches every request. Choosing it late means re-threading identity through code you have already written.
- The data model behind the loop. Get the core entities right early; renaming and reshaping tables after you have customer data is slow and risky.
The through-line: cut anything you can add cheaply later, keep anything that is cheap now and ruinous to retrofit. That single trade-off is what separates an MVP that ships in 6 to 12 weeks from one that slides into next quarter. Callidus, with all of the keep-list baked in, shipped solo in about 10 weeks — and it replaced an earlier FlutterFlow attempt that had collapsed under roughly 200 errors, which is its own lesson in scoping the build correctly the first time.
FAQ
How many features should a SaaS MVP have? There is no magic number — count the features your one core loop physically cannot run without, and that is your MVP. For most products that lands at a handful, plus the invisible essentials of tenancy, billing, and auth. If your list is long, you have probably bundled more than one product into one launch.
Should I use RICE, MoSCoW, or another scoring framework? Those frameworks are fine for an established product with a backlog and usage data. For an MVP they over-engineer the decision, because you have no real data to score against yet. Start with the one-loop test plus the three axes — loop dependency, build cost, retrofit pain — and adopt RICE later once real customers are generating signal.
What if a customer asks for a feature I cut? Good — that is the system working. A feature pulled in by a paying customer is far better evidence than a feature you guessed at. Add it when the request is real and recurring, build the thinnest version first, and you will have spent zero time on features nobody actually wanted.