SaaS MVP architecture: what to build in version one

Version one of a SaaS product should be one deployable application with one database, real authentication, a small explicit data model, and third-party integrations only at the edges. It does not need a mesh of services. It needs a shape you can deploy, reason about, and hand over in two weeks.

One app, one database

A modular monolith is the default. Auth, the core workflow, billing webhooks and the admin screen can live in one codebase with clear folders. Split a service out later if a part of the system independently fails, scales, or is owned by a different team. None of that is true on day one.

Folders do the work that services would do later. A structure that ages well looks roughly like this:

• Auth for sessions, roles and the middleware that guards routes
• The core domain, named after the thing the product is about, holding its records and rules
• Billing for checkout and webhook handling, touched by nothing else
• Admin for the screens only your team sees
• Integrations, one folder per provider, each with a thin client

The rule that keeps this useful: features talk to a module through its own functions, not by reaching into its tables. When a module later needs to become a service, you already know its boundary.

Auth is a product surface

Sign up, login, password reset, and at least one role besides "owner" belong in v1 if customers will actually use the thing. Skipping auth to "move faster" usually means you cannot put a real user on staging.

Keep roles boring. Owner, member, admin. Exotic permission matrices are how a sprint quietly becomes a month.

Two decisions are worth making deliberately, because both are painful to change later:

• Where the tenant boundary sits. Most products are account-scoped, and every query filters on the account. Decide this once, enforce it in one place, and never let a screen query without it.
• Whether a user can belong to more than one account. If yes, membership is its own record and the model is different from day one. If the answer is genuinely no, say so in writing.

Job Hunt is a clean example of the shape mattering: candidates and employers get separate accounts, so the permission question is answered by the account type rather than a matrix of toggles.

The data model is the spec

If you cannot draw the core records and how they relate, you cannot estimate the screens. A first SaaS is usually a handful of objects: account, user, the thing the product is about, and an event or job that happens to it.

Do not generalise those objects into a "flexible platform". Flexible is how v1 never ships. Concretely, that means avoiding the three patterns that always look clever in week one:

• A generic entities table with a type column standing in for real tables
• Key-value "custom fields" before a single customer has asked for one
• A homegrown workflow engine where a status column and three transitions would do

Xntral shows how ordinary the right answer looks. Users, patients, locations and functions are real records, and recurring appointment scheduling runs against them. The calendar is a view of those records, not a separate product with its own store of truth. That distinction is what keeps a scheduling feature from becoming a second system.

Get four things right in the schema and most of v1 goes smoothly:

• Every row that belongs to a customer carries the account id
• Timestamps on creation and update, everywhere, from the start
• Soft deletes where a customer would panic if a record vanished
• Enums for status, with the allowed values written down in the code rather than typed as free strings

APIs at the edges, not in the middle

Talk to Stripe, email, and one CRM if the workflow dies without it. Do not invent an internal public API for a single Next.js app with one client. You can extract one later from a module that already has a boundary.

For each integration, keep the client thin and put it behind your own function. Then the rest of the app depends on your names, not the provider's. That is what makes a provider swap a one-file change instead of a search across the codebase.

Two edge cases worth handling in v1, because they are the ones that actually happen:

• The provider is down. Decide whether the user sees an error or the work is queued. Either is fine. Silence is not.
• The provider sends the same event twice. Webhook handlers need to be safe to run twice on the same event. Store the provider's event or object id and check it before acting.

AI providers sit in this same category. Adey Studio integrates across Adobe CC, Google Drive, Dropbox, OneDrive, OpenAI and Claude, and the useful discipline is identical: each one is an edge, with your own interface in front of it, so the workflows on the canvas do not care which provider is behind a step. If you are shipping a model-backed workflow, AI product development is the sprint shaped around that.

Deployment should be boring

One environment you deploy to on every merge, plus a staging URL a client can open, covers a 14-day build. Managed hosting and a managed database are the right defaults. You want a rollback you can perform without a meeting, not an orchestration layer.

Add just enough operational visibility to answer questions in week three: error tracking, request logs, and a way to see whether a background job ran. That is the whole list.

What to refuse in v1

Multi-region, a rewrite of the design system, a custom billing engine, and "we might white-label this". Those are later sprints, paid for after people use the first workflow.

Also on the refusal list: a microservice split, a shared component library extracted before there is a second app, event sourcing, a feature flag platform, and caching added before anything has been measured as slow.

Architecture for a 14-day MVP is mostly subtraction. The skill is leaving a door open without walking through it yet.

If you have not fixed the scope yet, start with how to scope a first SaaS system in 14 days. If billing is in v1, Stripe billing for SaaS MVPs covers the smallest version that works. If part of what you are building faces customers directly, when your SaaS needs a customer portal is the deciding question.