Building a SaaS Product: Architecture Decisions You Can't Undo

In short: In a SaaS product most things can be changed later, but a few barely can: how tenants are separated, how the core data is structured, how users and permissions work, and where the data lives. Make those decisions deliberately before writing product code. Almost everything else, from the framework to microservices versus monolith, you can keep pragmatic.

Why some architecture decisions get expensive

Software can change, but not everywhere with equal ease. Rebuilding a screen takes a few weeks. Changing how different customers' data is separated touches every query, every table and every customer who already has production data in the system. Those changes get more expensive with every month in production, because migrations involve real customer data and must not cause downtime.

The good news is that the list of truly hard decisions is short. Once you know it, you can build the rest of the product quickly and iteratively.

Multi-tenancy: the foundation of SaaS architecture

Multi-tenancy describes how one system manages data for many customers. There are three common models.

Shared database with a tenant ID

All customers share tables and every row carries a tenant ID. It is cheap to run and easy to scale. The risk is discipline: one query without a tenant filter can show one customer's data to another. PostgreSQL's row-level security adds a safeguard inside the database that catches such mistakes.

Schema per tenant

Each customer gets its own schema in the same database. Separation is clearer, but migrations have to run for every schema, which becomes tedious with many customers.

Database per tenant

The strongest isolation, often requested by large customers or regulated industries. Operational effort and cost rise considerably. A common compromise is a shared model for most customers and dedicated databases for a few enterprise accounts, provided the architecture plans for it from the start.

The data model and database choice

Your product's core objects (customers, projects, contracts, bookings) and their relationships shape the system for years. For most B2B SaaS products a relational database such as PostgreSQL is the safe choice, because business data is almost always heavily related and needs transactions. Document databases have their strengths but are less often the better primary store for classic business processes. Our database selection guide for PostgreSQL and MongoDB goes into more detail.

Plan early for applying schema changes in production as well. Versioned migrations belong in the project from day one.

Authentication, roles and permissions

How users sign in and what they may do looks like a detail at first. In practice, B2B customers soon ask for single sign-on through their own identity provider, roles with different permissions, and users who belong to several organizations. If you start with "one user, one account, one password", rebuilding it later is painful.

It pays to either use an established identity service or model organizations, memberships and roles from the start. We explain the technical basics in implementing authentication with OAuth, JWT and sessions.

Hosting, data location and lock-in

For German and European business customers, data location is often a buying criterion. Moving from a US data center to the EU later is possible, but laborious and risky for operations. Choose the region deliberately. Our post on data hosting in Germany explains why it matters to so many buyers.

Also watch how deeply you tie yourself to a cloud provider's proprietary services. Managed databases and storage make sense. When business logic lives only in vendor-specific functions, switching becomes practically impossible.

What you can safely leave open

Many teams spend too long on questions that are easy to change later. Splitting into microservices is one: a well-structured monolith carries most SaaS products a long way. Caching strategy, frontend framework details and the deployment tool can also be adjusted once real usage shows where the bottlenecks are.

Frequently asked questions (FAQ)

Which tenancy model suits a new SaaS product?

For most new products, a shared database with a tenant ID and row-level security is the best start. It keeps cost and operations lean. Carry the tenant ID consistently everywhere so that moving individual customers to separate databases later stays possible.

Should a SaaS start with microservices?

Usually not. Microservices solve the problems of large teams and very different load profiles. For a young product they mainly add operational overhead. A modular monolith can be split later along clear boundaries.

How important is server location for German B2B customers?

Very important for many of them, especially with personal data and in regulated industries. EU hosting simplifies GDPR documentation and answers a question that comes up in almost every procurement process.

Can these decisions be corrected later?

Yes, at a high price. Any change to the tenancy model or user structure affects existing customer data and needs careful zero-downtime migrations. That is why an extra half day of planning at the start is worth it.

Conclusion

Good SaaS architecture comes from taking the few hard-to-reverse points seriously and keeping the rest deliberately simple. Tenant separation, data model, permissions and data location deserve the time, and most other things can grow with the product.

If you are planning a SaaS platform and want to work through these decisions with experienced engineers, talk to us about web development for SaaS products.