How to Build a SaaS MVP

The two decisions you cannot defer

Tenancy. How customer data is isolated is the architectural choice with the worst reversal cost in SaaS. Start with a shared schema and a tenant column, enforced by Postgres row-level security so a forgotten filter returns nothing rather than another customer's rows. Resolve tenant context in one place — that's what makes moving to per-tenant databases feasible later if an enterprise contract demands it.

Your pricing unit. Per seat, per usage, per workspace, or flat. This shapes your data model, because you have to be able to count the thing you charge for. Retrofitting a usage meter into a product built for seats is a genuinely painful migration.

Everything else — SSO, audit logs, admin panels, granular roles — can be added after you have customers who need them.

What a SaaS MVP contains

The one workflow that solves the problem, end to end
Sign-up, sign-in, password reset — use an auth provider, don't build it
Two roles at most: admin and member
The ability to invite a teammate, because B2B software spreads inside accounts
Instrumentation on activation and retention

What to skip at launch

Billing. Under about ten customers, invoice manually. A signed contract and a paid invoice prove willingness to pay better than a Stripe integration, and manual invoicing teaches you what your pricing should be before you encode it.

Granular permissions. Admin and member covers almost every early customer. Role hierarchies are enterprise-sales features, not product-market-fit features.

SSO. Real requirement — for enterprise deals you don't have yet. Add it when a contract names it.

An admin panel. Query the database. It's faster than building CRUD screens for yourself.

Onboarding is the feature teams skip and shouldn't

B2B SaaS lives or dies on time-to-first-value. If a new account has to configure five things before the product does anything useful, most never get there.

Seed sensible defaults, and where the product needs customer data to be useful, import it for them during the first call. Manual onboarding at low volume is the highest-return unscalable thing you can do.

Timeline and what actually slows it

Two to three weeks for a scoped single-workflow SaaS MVP with tenancy, auth, invites, and instrumentation. Overruns come from decision latency — an unanswered product question stalls the build far more often than an engineering problem does.

Specific builds

Deeper breakdowns of products in this category:

How to Build an App Like Notion

FAQ

What should a SaaS MVP include?

One workflow end to end, authentication via a provider rather than built in-house, two roles (admin and member), teammate invites since B2B software spreads inside accounts, and instrumentation on activation and retention. Multi-tenancy and your pricing unit must be decided up front; almost everything else can wait.

Should a SaaS MVP have billing at launch?

Usually not. Under roughly ten customers, invoice manually — it proves willingness to pay just as well and teaches you what your pricing model should be before you encode it in software. Building billing early often means rebuilding it once real pricing emerges.

How long does a SaaS MVP take to build?

Two to three weeks for a scoped single-workflow product with tenancy, auth, invites, and analytics. The usual cause of overrun is decision latency rather than engineering — a product question left open for days costs more than any technical obstacle.