The word "minimum" in MVP is usually applied to the wrong things. Teams cut engineering quality to ship faster, then keep a feature list broad enough to appeal to everyone. That produces a fragile product with no clear buyer — the worst of both compromises.
The correction is to invert it. Cut features aggressively. Do not cut the foundational engineering that determines whether you can charge money, scale tenants and survive diligence.
What cannot be minimum
Four things must be real in the first release, because retrofitting them costs several times more than building them correctly:
- Multi-tenancy. Tenant isolation enforced at the query layer, with automated tests proving cross-tenant access is impossible. Retrofitting isolation into a single-tenant schema is one of the most expensive rewrites in software.
- Authentication and authorisation. Secure sessions, invitation flows, role enforcement server-side. A product that leaks data between customers does not recover reputationally.
- Billing. Subscription plans, trials, proration, failed-payment dunning and webhook-driven state reconciliation. If you cannot charge reliably, you have not built a business.
- Instrumentation. Activation and usage events defined and captured from day one. Added later, you have no baseline and cannot tell whether changes helped.
None of these are features customers ask for. All of them determine whether the product can be sold, operated and raised against.
What should be minimum
Almost everything else. In a recent engagement we cut a proposed feature list by roughly 60% to reach a v1 that could be sold rather than merely demonstrated. The cuts followed one rule: does a customer refuse to pay without this?
Features that regularly get deferred without harming launch:
- Configurable dashboards. Ship one well-designed default view.
- Granular permissions beyond two or three roles.
- Integrations beyond the single one your first segment genuinely requires.
- White-labelling and theming.
- Mobile applications, where a responsive web interface serves the initial use case.
- Bulk import and export tooling beyond a basic CSV.
- In-app onboarding tours, which a human onboarding call handles better at low volume.
Each of these is defensible eventually. None of them is why a first customer pays.
Choose one segment and design for it
The most damaging MVP decision is targeting two segments simultaneously. Serving "small firms and enterprises" means building configurability nobody needs yet, and marketing that persuades neither.
Pick the segment where the pain is most acute and the buying process is shortest. Design the product, pricing and onboarding for exactly them. Expanding to a second segment from a strong position in the first is straightforward; expanding from a weak position in both is not.
Price before you build
Pricing determines architecture. Per-seat pricing requires seat management and invitation flows. Usage-based pricing requires metering infrastructure that is genuinely difficult to add later. Tiered pricing requires feature gating designed into the permission model.
Deciding pricing after the build means either rebuilding or accepting a pricing model that does not fit your value. Decide the model — not necessarily the exact number — before architecture.
Realistic timelines
A focused SaaS MVP with real multi-tenancy, billing, auth and instrumentation typically reaches production in 10–16 weeks. The largest variable is not engineering speed but decision speed on scope. Teams that can say no to features ship at the fast end of that range.
Budget-wise, our SaaS MVP engagements start at $12,000 and commonly land between $35,000 and $70,000 depending on domain complexity and integration count. Significantly cheaper proposals usually omit one of the four non-negotiables, which is a cost deferred rather than avoided.
The diligence test
A useful discipline: build as though a technical due diligence review happens in twelve months. That means documented architecture, tested tenant isolation, secret management, dependency scanning and a deployment pipeline. Teams that do this pass diligence without remediation; teams that do not spend their raise period fixing foundations instead of growing.
Want this applied to your operation?
A free 45-minute discovery call will establish whether the framework above applies to your situation, and what it would cost to act on it.