SaaS MVP Decisions That Matter Before the First Build
A SaaS MVP is not a miniature version of the finished roadmap. It is the smallest dependable service that can test a specific customer promise with real users and produce evidence for the next decision. That definition changes what belongs in the first build. A narrow workflow, explicit tenant boundary, recoverable data model, visible failure state, and measurable outcome matter more than a long list of polished screens. The first release should be small in scope but serious about the consequences of being trusted.
Choose one customer promise
Write the promise as an observable before-and-after statement: a support lead can assign an incoming case in under five minutes; a finance team can reconcile a recurring invoice without a spreadsheet; a field manager can see which work orders are blocked. Avoid promises such as ‘centralize operations’ that cannot define success. Name the user, trigger, decision, output, and time horizon. If the team cannot show a before state and a completed after state, the MVP is probably a collection of features rather than a product slice.
Use the learning loop described by the Lean Startup method as a product constraint: decide what must be learned, build only what exposes that uncertainty, measure a behavior, and decide whether to continue, change, or stop. Interviews and prototypes can test language and desirability; a working slice is needed to test repeat behavior, latency, permissions, and operational effort. Keep those questions separate so a nice demo does not masquerade as product evidence.
| Decision | Useful question | MVP evidence |
|---|---|---|
| Promise | What job becomes measurably easier? | Completed workflow and baseline |
| User | Who acts, approves, and receives the result? | Named roles and test accounts |
| Boundary | Which tenant, project, or account owns each record? | Negative cross-boundary tests |
| Learning | What result changes the next build? | Metric, interview note, or decision rule |
Make the data boundary real
Multi-tenant behavior is not a later scaling concern. It is part of the first trust contract. Decide the tenant key, ownership rules, administrator scope, deletion behavior, export behavior, and support access before designing queries. A record should carry enough context for the service to enforce scope on reads, writes, background jobs, search, files, and analytics. Do not rely on a hidden frontend filter or on a developer remembering to add a predicate to every query.
Start with one simple isolation model if it lets the team test the promise safely. Shared tables can be reasonable when every access path enforces tenant scope and the team has negative tests; separate databases can be appropriate when legal, operational, or customer requirements demand stronger isolation. The decision is less important than making it explicit, testable, and compatible with backup and restore. Edilec's workspace modeling guide, SaaS reliability guide, and RBAC checklist are useful adjacent reading.
Model states before screens
Early products often fail because a screen implies a state the backend cannot explain. List the lifecycle of the core object: draft, submitted, approved, running, blocked, completed, cancelled, or archived. For each transition, identify the actor, precondition, side effect, notification, retry behavior, and audit record. A payment can be pending even when an order is accepted; a support case can be closed while an external action remains unresolved. Keep those states distinct instead of making a single status carry every meaning.
| Object | State to distinguish | Why it matters |
|---|---|---|
| Subscription | trial, active, past_due, cancelled | Entitlement is not the same as payment timing |
| Job | queued, running, failed, retrying, succeeded | A retry must not duplicate an external side effect |
| Invitation | sent, accepted, expired, revoked | Membership should follow an explicit actor action |
Decide how the service will be operated
The Twelve-Factor App principles are a practical reminder that configuration, logs, processes, backing services, and deploys need clear boundaries. For an MVP, choose the smallest operational setup the team can inspect: one deployment path, a documented environment contract, structured logs, backups with a restore rehearsal, and a way to see failed jobs. A single engineer may own several duties, but the duties still need names. If nobody knows who pauses an integration or answers a data-recovery question, the product is not ready for real dependence.
Define the support path before launch. Give support a read-only view of authoritative state, a safe way to attach evidence, and a narrow escalation route for privileged actions. Keep customer data out of ad hoc production queries where possible. Record who accessed sensitive context, why, and what changed. This reduces the temptation to turn an MVP into a collection of emergency scripts that become permanent infrastructure.
Put security in the first slice
Security does not require every enterprise feature on day one, but it does require correct boundaries. Use a maintained identity provider or well-understood authentication library, protect sessions, enforce authorization on the server, validate input, separate secrets from source, and make production data inaccessible to casual development tooling. OWASP's Web Security Testing Guide is useful for turning those expectations into tests: attempt unauthorized object access, role changes, session misuse, injection, unsafe redirects, and exposed administrative paths.
Choose defaults that preserve optionality. A short-lived access decision, a versioned API contract, idempotency keys for retries, and a feature flag for risky behavior are usually easier to extend than an opaque shortcut. Avoid building a general permissions language before the product has two or three real permission cases. Capture the cases now; generalize only when their differences are understood.
Measure the decision, not the activity
Count the events that tell you whether the promise worked: time to first completed workflow, completion rate, correction rate, repeat use, manual support time, and the number of records left in an unknown state. Pair product metrics with service measures such as failed jobs, latency, recovery time, and authorization denials. A high sign-up count does not prove value if users do not finish the job; a low error rate does not prove reliability if failed work disappears silently.
Use a small set of launch gates
Key takeaways
- Anchor the first build to one observable customer promise.
- Make tenant boundaries, lifecycle states, recovery, and authorization testable from the start.
- Use operational evidence to decide what the next build should change.
Keep billing and entitlement states separate
A subscription product has at least three different truths: the commercial agreement, the payment processor's state, and the access the application grants. A customer can have an active subscription with an invoice awaiting payment, or a successful payment with an entitlement that has not yet been provisioned. Model those states independently. Stripe's Billing documentation is a useful official reference for subscriptions, invoices, payment intents, and lifecycle events, but the product still needs to decide which event changes access and which event merely starts reconciliation.
Use an idempotency key when creating or retrying a charge, invoice, provisioning job, or webhook response. Store the provider event identifier and the internal outcome together. If the provider sends the same event twice, the second delivery should be harmless; if events arrive out of order, the application should reconcile from authoritative provider state instead of blindly applying an older transition. A small MVP does not need every billing feature, but it does need a visible path for pending, failed, refunded, disputed, and manually reviewed states.
Plan for schema and data changes
The first customer will discover fields and workflows that the team did not anticipate. Make changes additive where possible: introduce a nullable field, backfill it, observe it, and only then make it required. Keep migrations separate from application deploys when a large table or important workflow is involved. Record who ran a migration, which version it expected, and how to repair a partial run. A rollback that restores code but not data can be more dangerous than a forward fix.
Decide what can be deleted, archived, corrected, or exported before the first customer asks. Soft deletion can help with recovery but should not become indefinite retention of sensitive data. An export should carry the tenant, time range, source version, and status so a customer can distinguish a complete export from one that is still being generated. These decisions also keep analytics honest: a deleted account should not quietly remain in a product metric without a documented reason.
Make releases reversible in practice
A feature flag is useful only when its owner knows what it controls and how to turn it off. Pair flags with a migration plan, an exposure cohort, a success measure, and a removal date. For integrations, protect new behavior with timeouts, bounded retries, circuit breaking, and a manual queue rather than allowing a provider slowdown to consume every worker. Keep the previous behavior available only when it is safe and understood; a hidden dual path can create two sources of truth.
After each release, review one successful case, one failed case, one support interaction, and one operational signal. Ask whether the product made the promised job easier and whether the team could explain every state transition. This review is deliberately small: it prevents the MVP from becoming a sequence of guesses while preserving the speed needed to learn.
Before inviting external users, prove the happy path with realistic data, then prove the negative paths. Test tenant separation, duplicate submissions, expired sessions, partial payment, provider downtime, backup restore, failed notification, and a deploy rollback. Ask a person who did not write the feature to complete the workflow and explain what happens when it fails. The test is not ceremony: it exposes assumptions the builder has unconsciously filled in.
- One customer promise has an observable completion state and a baseline.
- Every core record has an owner, lifecycle, tenant boundary, and recovery story.
- Authorization and session behavior are tested on the server, including negative cases.
- Jobs, payments, integrations, and notifications have idempotent or reconciled outcomes.
- Operators can inspect failures, restore data, and reach a named decision maker.
- The next build is selected by evidence rather than by the loudest feature request.
Frequently asked questions
Should an MVP build its own authentication?
Usually not. Use a maintained provider or library and spend product effort on the customer workflow, authorization boundary, recovery, and support experience. Own the integration contract and session policy even when a provider handles credentials.
Does a SaaS MVP need multi-tenant architecture?
It needs an explicit customer boundary from the first shared record. The implementation can be simple, but every query, job, export, search path, and support action must preserve that boundary.
What should a SaaS MVP prove first?
Prove one observable customer promise with a measurable completion state, a defined user, and evidence that the workflow is worth expanding. A narrow proof makes the next build decision clearer than a broad feature inventory.
Conclusion
A useful next comparison is Edilec's workspace modeling guide, which applies the same boundary discipline to identity, membership, data scope, and lifecycle. The GOV.UK beta guidance supports staged learning before scale; Microsoft's multitenant architecture guidance details tenant boundaries; the AWS SaaS Lens frames workload decisions; and GOV.UK's service design guidance keeps user needs and evidence in view.
The best SaaS MVP decisions make learning and trust reinforce each other. Choose one promise, model its states, enforce the data boundary, protect the first real users, and operate the service with evidence. That discipline keeps the first build small without making it disposable.