Most first versions fail in one of two ways. They are built as a demo that cannot take a real customer, or they are built for a scale that has not arrived and never ship at all.
The useful definition of a minimum viable product is narrow: the smallest thing a stranger can pay for and get value from without you in the room.
The five things a paying customer requires
A demo needs a screen. A first release needs a spine. These five are not optional, and leaving one out is what turns a launch into a rebuild:
- Sign-up and authentication. Accounts, sessions, password reset, and invitations if teams are involved.
- Tenant isolation. Every query scoped to the customer it belongs to. Getting this wrong is not a bug; it is a data breach.
- Billing and entitlements. Plans stored in your own database, so what a user may do never depends on parsing a webhook at the moment they click.
- An admin surface. A way for you to see accounts, fix data and support customers without opening a database client.
- Instrumentation. Events for sign-up, activation and the core action, so you can tell whether anyone actually uses the thing.
Note that none of these are features of your product. They are the cost of having customers, and they are why an MVP is more work than a prototype.
Choosing the one workflow
Pick the single sequence that produces the value you intend to charge for, and follow it end to end. Not three half-built journeys — one complete one, including the unglamorous parts: empty states, errors, the second visit.
A test that works: describe the product in one sentence of the form "it lets [someone] do [thing] without [current pain]". Anything that is not on the path of that sentence is phase two.
Decisions that are expensive to reverse
Spend a day on these before writing product code:
- Tenancy model. Shared schema with a tenant key, schema per tenant, or database per tenant. This shapes every query, migration and backup you will ever run.
- Permissions. Roles, resource ownership and how you will express "this user may do this to that". Retrofitting it means auditing every endpoint.
- Entitlements. What a plan grants, expressed in your own data rather than inferred from the payment provider.
- Background work. What happens off the request path — emails, exports, syncs — and what happens when one fails twice.
- Data you will regret not recording. Created-at, updated-at, actor, and an event log. Cheap now, impossible retroactively.
What can wait
Almost everything else, and saying so out loud is the job:
SSO and SAML until an enterprise buyer asks. Granular roles until a customer has more than a handful of users. A public API until someone wants to integrate. Multi-region hosting until latency is a complaint rather than a hypothesis. A redesign until real usage tells you which screens people actually live in.
How we phase it
Phase zero is a short written architecture: tenancy, data model, integrations, and the list of decisions above with an answer against each.
Phase one is the spine plus the one workflow, deployed, with billing live and analytics recording activation.
Phase two is decided by what the first users do, not by the backlog written before anyone used it.
That is how SaaS development runs here — published starting points are on pricing, and anything larger is quoted against the written scope. If you are not sure whether you are building a product or an internal tool, this decision guide is the shorter question to answer first.
Frequently asked questions
- What should a SaaS MVP include?
- One workflow done completely, plus the machinery a paying customer requires: sign-up and authentication, tenant isolation, billing and entitlements, a way for you to administer accounts, and enough instrumentation to see whether anyone activates. Everything else is phase two.
- How long should a first version take?
- Eight weeks is a realistic target for a focused scope, and the way to protect it is to cut features rather than extend the date. If the scope cannot ship in a quarter, it is not a minimum version.
- What decisions are expensive to reverse later?
- Tenancy and data isolation, the permissions model, how billing entitlements are stored, and where background work runs. These are cheap to get right at the start and painful to change once customers depend on them.
- Should we build on a no-code platform first?
- Sometimes — to validate demand, absolutely. The trap is the second year, when the platform's limits become your product's limits and the migration costs more than the original build would have.
- saas
- mvp
- product
- architecture
