The SaaS MVP checklist: what to build, and what to refuse to build
A SaaS MVP needs four things: signup and onboarding that reaches value without a call, one complete core workflow, working payments, and analytics on activation. Everything justified by 'we will need it eventually' belongs in phase two, because the first fifty users will change what eventually means.
Key takeaways
- Ship billing in version one. A product nobody has paid for has not been validated.
- Add the tenant boundary before your first customer, even with one customer.
- One user type, one workflow, one paid plan.
- Reserve a third of the budget for the eight weeks after launch.
Nearly every MVP scope we are sent could lose forty percent of its features without a first customer noticing. The features are not bad ideas — they are answers to questions nobody has asked yet.
In version one
- Signup and onboarding that gets a stranger to the point of value without a sales call.
- One complete workflow, end to end, for one user type.
- Payments, live and tested — a product nobody has paid for is a prototype with good manners.
- Activation analytics, so week four tells you something rather than nothing.
- A tenant boundary, even with a single customer.
- An admin view good enough for you to support a customer without a database client.
Cut from version one
- A second user role, before the first has anyone in it.
- A settings page with fourteen toggles whose defaults have never been tested.
- Integrations requested in deals that have not closed.
- A mobile app alongside the web app in the same release.
- Anything justified by the phrase we will need it eventually.
The four decisions that are expensive to reverse
- Tenancy model
- Shared schema with a tenant column, schema per tenant, or database per tenant. Retrofitting a boundary later means rewriting every query you have written. Start with shared schema and row-level security unless a contract requires otherwise — the reasoning is in multi-tenant SaaS architecture.
- Identity and permissions
- Roles, organisations and invitations. Enterprise buyers ask for SSO eventually; building on a provider that supports it costs nothing now and saves a rebuild later.
- Billing and metering
- Plans, seats, usage, trials, proration and dunning, reconciled against your own records rather than trusted from a redirect. Bolted on late, billing becomes the most bug-prone system you own.
- Event instrumentation
- Activation, retention and feature usage tracked from the first release. Without it, every roadmap decision after launch is an opinion with a deadline.
Twelve weeks, honestly
| Weeks | What happens | What you have at the end |
|---|---|---|
| 1–2 | Definition, architecture, core flow design | Scope and a tested prototype |
| 3–8 | Build in three sprints, billing included | A staging URL each fortnight |
| 9–10 | Private beta, 10–30 instrumented users | Findings and a fix list |
| 11–12 | Fixes, launch page, tracking, go live | A product taking payments |
If your timeline says twenty-four weeks, the scope contains a phase two. Find it and move it. The full engagement is on SaaS Product Development, and the scoping argument is in MVP development.
Selling into India
Localisation is a feature rather than a formality: UPI and mandates, GST-compliant invoicing a chartered accountant will accept, WhatsApp for transactional notification, and address formats that match how people write them. Global products routinely lose Indian customers to support burden created entirely by these gaps.