SaaS MVP Development
A SaaS MVP has two things a general MVP does not: it must be multi-tenant from the first line, and it usually has to take money. Both are cheap to build in at the start and genuinely painful to add later.
Discuss your projectThe two things not to defer
Multi-tenancy is the first. It is tempting to build for one customer and generalise later, and it is a false economy — retrofitting tenancy means revisiting every query, every permission check and every background job to make them tenant-aware, and the ones that get missed are data leaks between your customers. Built in from the start, with the boundary enforced at the database rather than only in application code, it costs very little.
Billing is the second, if your MVP is testing whether people will pay. Not an invoicing system — Stripe, with subscriptions, and your own entitlement state kept consistent with what Stripe believes. The reason not to defer it is that "would you pay for this?" and "here is a card field" produce completely different answers, and the whole point of the MVP is to get the real one.
Almost everything else can wait. Team invitations, roles beyond the basics, an admin interface, a settings page, onboarding flows, integrations, a marketing site — all genuinely deferrable. The discipline is in deferring them, and most of the value we add in scoping is arguing things out of version one.
What a SaaS MVP includes
One workflow, finished
The thing your product exists to do, working end to end on real data, with the edge cases that matter handled rather than deferred.
Tenancy enforced at the data layer
So a missing filter in one query cannot expose another customer's records. We write tests that attempt cross-tenant access and expect them to fail.
Sign up, sign in, reset
Using well-trodden components rather than built from scratch. Necessary, unglamorous and quick.
Subscription billing
Stripe, with webhooks handled idempotently so a retried event does not double-charge. Included when the question you are testing is commercial.
Instrumentation on the core action
Whether people complete the workflow, whether they return, whether they convert. Without this you will have opinions after launch instead of evidence.
Deployment and a pipeline
You will be shipping changes weekly during the learning phase, so deploying has to be boring from day one.
Deliberately left out of version one
Each of these is real work and none of them answers the question you are testing.
- Team accounts and granular roles, unless collaboration is the product itself.
- An admin interface for your own team — a database client is sufficient for your first dozen customers.
- Settings and preferences pages, which exist mostly to defer decisions about defaults.
- Integrations, unless one integration is the reason people would buy.
- A marketing site, which is a separate and much cheaper piece of work.
- Email notification preferences, beyond the ones the workflow requires.
- Usage-based billing, unless you are specifically testing it — though metering should be recorded from the start if you think you will need it later, since you cannot bill for a past you did not measure.
- SOC 2 and compliance certification, which matters when you are selling to enterprises and not before. Building audit logging and access control properly from the start is the part that makes it cheaper later.
Common questions
Related in Dedicated Development Teams
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch