A SaaS MVP is not merely a web app with a pricing page.
The moment several paying customers share one product, architecture changes.
You need to think about:
- customers/organisations;
- users;
- workspaces;
- roles;
- tenant isolation;
- subscriptions;
- plan limits;
- admin controls;
- billing state.
For 2026 planning:
| SaaS stage | Planning budget |
|---|---|
| Narrow validation SaaS | $10k–$25k |
| Production B2B SaaS MVP | $25k–$60k |
| Complex multi-role SaaS | $60k–$120k+ |
| Regulated / enterprise SaaS | Scope individually |
The first release still needs SaaS foundations
A disciplined MVP does not need every roadmap feature.
But if real customers will create accounts and pay, the product normally needs:
- authentication;
- organisation/workspace model;
- tenant isolation;
- core workflow;
- billing;
- enough admin tooling to support users;
- transactional email;
- production deployment;
- monitoring/recovery basics.
Cutting those blindly can create a demo that is expensive to turn into a product.
Multi-tenancy is not “add company_id”
Suppose Company A and Company B use your SaaS.
Their data should be separated.
Now add:
- a consultant who belongs to both;
- owner/admin/member roles;
- invitations;
- account transfers;
- archived organisations;
- a platform support user.
The relationships need to be explicit.
Supabase documents Row Level Security as granular authorization inside Postgres and identifies multi-tenant applications as a natural use case. See Supabase RLS.
Whatever stack you use, tenant isolation deserves direct tests.
Authentication is only the entrance
Your MVP may need:
- password login;
- magic links;
- social login;
- invitations;
- password reset;
- session handling;
- account deletion;
- later MFA or enterprise SSO.
The difficult question is rarely “can the user log in?”
It is:
What happens to every related record when this user’s access changes?
Subscription billing has a lifecycle
Stripe’s current Subscription object includes statuses such as incomplete, trialing, active, past_due, canceled, unpaid and paused. See Stripe’s Subscription API reference.
That means your product needs business rules for:
- failed first payment;
- trial ending;
- failed renewal;
- grace period;
- cancellation;
- reactivation;
- upgrade/downgrade;
- seat changes;
- webhook retries.
Billing is product state.
Do not reduce it to one Boolean called isPaid.
Pricing model affects architecture
Stripe’s billing documentation distinguishes models such as flat-rate, per-seat, tiered and usage-based pricing. See Stripe recurring pricing models.
Decide your pricing model early enough that the data and entitlements can support it.
A per-seat product needs seat counts and membership lifecycle.
A usage-based product needs trustworthy usage metering.
Admin tooling is part of the MVP
The first customer will eventually need help.
Your internal admin area may need to show:
- users;
- organisations;
- subscription state;
- support actions;
- audit information;
- plan/entitlement state;
- system issues.
You do not need to automate every support action.
You do need enough control to operate the product safely.
Do not support five customer types at once
A common MVP mistake is designing version one for:
- freelancers;
- agencies;
- schools;
- enterprises;
- nonprofits.
Each audience introduces different workflows and permissions.
A stronger MVP chooses:
one customer type + one painful workflow + one clear reason to pay.
Expand when real behaviour justifies it.
Where SaaS budgets disappear
Entitlements
Different plans unlock different capabilities.
Permissions
Owner, admin, member, viewer, collaborator.
Billing edge cases
Trials, failed renewals, upgrades and cancellations.
Integrations
Every provider introduces new failure states.
Reporting
Customers gradually ask for more flexible visibility.
Migration
B2B customers often already have data.
Support tooling
Operations become real when customers become real.
AI can compress implementation, not responsibility
AI-assisted development can speed up:
- UI scaffolding;
- repository work;
- tests;
- documentation;
- debugging;
- refactoring.
It does not remove decisions about tenancy, permissions, billing state, migrations or production safety.
If your SaaS is AI-assisted, see my AI-generated code review before production and production checklist.
What should be in the first scope?
Define:
- target customer;
- core workflow;
- roles;
- organisation/workspace model;
- pricing model;
- billing behaviour;
- minimum admin controls;
- required integrations;
- events you need to measure;
- launch criteria.
Then everything else has to earn its place.
The goal is the first reliable paying customer
An MVP is successful because it creates evidence.
Not because it contains 60 features.
If one workflow can convince the right customer to pay, build that workflow properly.
If you are planning a SaaS product and need help turning the idea into a smaller production-ready first release, send me the customer, problem and core workflow or review my MVP development service.
