What Should Your First SaaS MVP Include? A Founder's Feature-Prioritisation Guide
Scope a B2B SaaS MVP around your riskiest assumption: a scoping worksheet, an in, out and later table, and the security basics you should never cut.
What a first SaaS MVP should include
A first SaaS MVP should include the smallest set of features that lets real customers test your riskiest assumption, plus the features needed for them to trust you with their data: sign-in, access control so each customer sees only their own data, basic audit logging, and backups with a way to export data. Everything else goes on a later list, or is done manually. The test for each feature is not "is it useful?" but "do we need it to learn what we must learn, or to be trusted?"
This follows Eric Ries's original definition. In his 2009 guide to the minimum viable product, he describes it as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." The aim is learning, not a smaller version of the full product.
Key takeaways
- Write down the one assumption the MVP must test before listing features.
- Sort every feature: needed to test the assumption, needed for trust or legal reasons, or neither.
- "Neither" goes to the later list, or is done manually behind the scenes.
- Do not cut authentication, access control, basic audit logging, or backups and export.
- Use RICE, Kano or MoSCoW to order the later list, not to decide the first version.
- A heavier MVP is justified when regulation or customer trust demands it, not because a competitor has a feature.
Step one: name the riskiest assumption
Most SaaS ideas rest on several assumptions: that a problem exists, that this customer feels it strongly enough to change how they work, that your workflow solves it, and that they will pay. The riskiest one is the assumption that, if wrong, makes the rest irrelevant, and that you have the least evidence for.
Write it as a sentence you could prove false: "Operations managers at 20 to 200 person logistics firms will replace their shared spreadsheet with our scheduling board within two weeks of onboarding." Then write down what result would count as evidence, and by when. If you cannot name the assumption, you are not ready to scope an MVP; you are ready for customer interviews or a prototype. The guide to how much UX design to do before development covers that stage.
The scoping worksheet
List every candidate feature as a row and fill in the columns. Be strict with the second column: a feature is required to test the assumption only if, without it, a customer could not complete the workflow you are testing.
- Yes in either of the first two columns: in the first version.
- No in both, but the customer must experience the outcome: do it manually. A team member performs the task behind the scenes (sometimes called a concierge or Wizard-of-Oz approach). It is slower per customer but costs no build time and teaches you what the automated version must do.
- No in both, and the outcome is not needed yet: later list.
- No in both, and it does not serve the assumption at all: out. Write down why, so it does not return in the next meeting.
| Candidate feature | Required to test the assumption? | Required for trust or legal reasons? | Can it be done manually first? | Decision |
|---|---|---|---|---|
| Write each feature here | Yes / No | Yes / No (security, consent, privacy, payments) | How, and by whom | In / Manual / Later / Out |
In, out and later: a typical B2B SaaS
This is a starting point for a typical B2B SaaS product where a team at a customer company uses a shared workspace. Your assumption may move rows; the trust rows should not move.
| Feature | First version | Why |
|---|---|---|
| The core workflow you are testing | In | It is the experiment |
| Sign-in for invited users | In | Trust; a proven identity provider reduces build effort |
| Per-customer data separation and roles (at least admin and member) | In | Trust; one customer must never see another's data |
| Basic audit log of sign-ins and key changes | In | Trust and support; you need to answer "who changed this?" |
| Backups and data export | In | Trust; customers need to know they can leave with their data |
| Privacy notice and the consents your market requires | In | Legal |
| Simple onboarding (invite a teammate, sample data) | In, if adoption is the assumption | Otherwise do it manually on a call |
| Self-serve billing and plan management | Later, unless willingness to pay is the assumption | Invoice the first customers manually |
| Self-serve sign-up | Later | Invite early customers by hand so you speak to each one |
| Integrations | Manual or later | Import a spreadsheet; build the integration that customers ask for most |
| Reporting dashboards | Later | Export data and build reports by hand for the first customers |
| Advanced permissions, single sign-on | Later | Add when a customer's procurement asks for it |
| Native mobile apps | Out | A responsive web app tests the assumption |
| Custom theming, white-labelling | Out | Rarely the riskiest assumption |
Do not cut these
Some ranking advice suggests skipping authentication in an MVP. For a B2B product holding customer data, that conflicts with the most widely used list of web application risks. The OWASP Top 10:2025 puts A01:2025 Broken Access Control first and lists A07:2025 Authentication Failures. An MVP with real customers and real data is exposed to both from the first day.
- Access control: every request checks that the user may see or change that record, on the server, not only in the interface.
- Authentication: use a proven identity provider or a well-tested library; include password reset or passwordless sign-in, and session expiry.
- Basic audit logging: sign-ins, permission changes and changes to important records, with who and when.
- Backups and export: automated backups you have tested restoring, and a way for a customer to export their data.
Key takeaway
These are cheaper to include from the start than to retrofit, because access rules touch every screen and every query. For API-level detail, see API security best practices.
Where RICE, Kano and MoSCoW fit
Prioritisation frameworks are useful once the first version is fixed by the riskiest assumption. Use them to order the later list and to explain decisions to co-founders and investors.
| Method | What it is | Best used for | Watch out for |
|---|---|---|---|
| RICE | Described by Sean McBride at Intercom in 2018: score each idea on reach, impact, confidence and effort; reach × impact × confidence, divided by effort, gives "total impact per time worked" | Ordering the later list once you have usage data | Before launch, reach and impact are guesses; keep confidence honest |
| Kano model | From Kano, Seraku, Takahashi and Tsuji (1984): sorts features into must-be qualities customers expect, attractive qualities that delight, and others | Spotting must-be features you might wrongly cut, and delighters you can postpone | Needs customer input to classify features, not internal opinion |
| MoSCoW | Sort items into must have, should have, could have and won't have this time | Quick agreement in a planning session | "Must" tends to grow; tie it to the riskiest assumption |
Hypothetical example: a scheduling tool for field-service firms
This example is hypothetical. A founder plans a SaaS tool that lets small field-service firms schedule engineers. Her list has 23 features. Her riskiest assumption is that office managers will move daily scheduling out of a spreadsheet and into the tool, and still be using it after four weeks.
Working through the worksheet, only four features are required to test that: a scheduling board, a job list, assigning engineers, and a daily view engineers can open on a phone browser. Four more are required for trust: sign-in, separation of each firm's data with admin and member roles, an audit log of schedule changes, and export to CSV. Customer import is done manually by the founder from each firm's spreadsheet. Billing is invoiced by hand. The integration with accounting software, route optimisation, native apps and reporting go to the later list. The other 15 features are either handled manually or not built for the first version.
After launch, she will order the later list with RICE using real usage data, and move route optimisation up only if customers ask for it.
When a heavier MVP is justified
Some products cannot start small on trust. If you handle payments, health records, financial data or children's data, or sell to large organisations whose security reviews come before any trial, the trust and legal column will be longer, and the first version will take longer to build. That is a reason to make the experiment column even shorter, not to skip the trust column. It may also be a reason to test the workflow with a prototype first, before any real data is involved.
Data protection rules also differ by market. If you are building in Australia or the UAE, the Australian MVP guide and the UAE MVP guide cover local funding, tax and regulatory points as further reading.
Common mistakes
- Listing features before naming the assumption, then cutting by gut feel.
- Cutting authentication or access control to save time, then retrofitting them under pressure.
- Building self-serve billing and sign-up before anyone has paid.
- Building integrations before customers agree which ones matter.
- Treating the later list as a promise to customers.
- Measuring success by features shipped rather than by evidence for or against the assumption.
After launch
Once customers are using the product, the question changes from "what is the smallest test?" to "what should we build next?". Review the result against the evidence you defined, then reorder the later list with real data. The SaaS roadmap prioritisation guide covers that stage. To budget the build itself, how to estimate the cost of a custom web application gives a worksheet that starts from the scope you have just defined.
Conclusion and next steps
Write down your riskiest assumption and the evidence that would prove it wrong. Put every candidate feature through the worksheet. Keep the experiment column short, keep the trust column intact, and do as much as you can manually for the first customers. Then brief a team with the in, manual and later lists, so they quote for the right thing. If you need a team to design and build it, see our web application development service.
Plan your MVP
ZSpace Labs is a remote-first technology studio that works with clients globally on product discovery and UX design and web application development. If useful, we can go through your scoping worksheet with you and talk through what belongs in the first version.
Sources
Definitions and methods: Eric Ries, "Minimum Viable Product: a guide", Startup Lessons Learned, 3 August 2009; Sean McBride, "RICE: Simple prioritization for product managers", Intercom, 5 January 2018; Kano, Seraku, Takahashi and Tsuji, "Attractive quality and must-be quality", Hinshitsu (Journal of the Japanese Society for Quality Control), vol. 14, no. 2, 1984.
Security: OWASP Top 10:2025.
Accessed 14 October 2026.
Common questions.
Only if the product holds no customer data that one user should not see. Most B2B SaaS products do, so you need authentication and access control from the first version. You can use a proven identity provider instead of building login yourself, which is usually faster and safer.