How to build a SaaS product: the early decisions that are expensive to change.

To build a SaaS product, get a handful of decisions right early and keep everything else simple. Decide how customers' data is kept apart, use a proven provider for sign-in, let a billing platform own subscriptions, pick a stack your team knows well, and refactor only when something is actually slowing you down.

Which SaaS decisions are expensive to change later?

The ones built into your data and your users' accounts: how tenants are separated, how people sign in and how billing status is stored. Changing these later means migrating live customer data or asking every user to log in again. Screens, features and most of the stack are far cheaper to change.

So be strict about those three and relaxed about the rest. A clumsy settings page can be rebuilt in an afternoon. A data model that mixes customers' records without a clear owner is a different kind of problem.

How should a SaaS product keep customers' data separate?

Choose a multi-tenancy model on day one. The common patterns are a separate database for each customer, a separate schema for each customer inside one database, or shared tables where every row carries a tenant ID. AWS guidance calls the fully separate end silo, the shared end pool, and the mixed approaches bridge.

• Database per tenant (silo). The strongest isolation, and backups or deletion per customer are simple. AWS notes it also brings the most cost and complexity, which grows with every customer you add.
• Schema per tenant (bridge). Separation at the schema level inside one database, but every change to the data structure has to be applied to every schema.
• Shared tables (pool). The lowest cost and the simplest to run, but isolation now depends on every single query filtering by tenant.

Our default for a new product is shared tables, with the tenant filter enforced in the database itself rather than left to application code. PostgreSQL's row security policies do this. Once row security is enabled on a table and no policy exists, nothing is visible at all. Superusers always bypass these policies, and so does the table's owner unless the table is set to force row security, which catches people out in testing.

Choose separate databases instead when a contract or regulator requires physical separation, or when a large customer needs its data in a particular location. The models can be mixed: pool most customers and give a dedicated database to the few who need one.

Get this wrong and one customer sees another's data. Few mistakes cost a SaaS business more trust.

Should you build your own login system?

No. Use an established authentication provider or a well-maintained open-source library. Authentication failures are one of the OWASP Top 10 web application risks for 2025, and OWASP recommends premade, well-trusted systems for authentication, identity and session management where possible. Building your own means owning password storage, resets and sessions for good.

Pick a provider that already supports what business customers will ask for later: multi-factor sign-in, sign-in with Google or Microsoft, and single sign-on through SAML or OpenID Connect. You do not need enterprise single sign-on at launch. You do want a provider where turning it on is a setting rather than a rebuild. Keep your own users table linked to the provider's user ID, so moving providers one day is a migration and not a rewrite.

How should you handle SaaS billing?

Let a billing platform own subscriptions, invoices, payment retries and tax, and keep a copy of each customer's plan and status in your own database. Your app reads its own copy to decide what a customer can use. The billing platform tells you when that status changes, and your app listens.

That listening is where early products break. Stripe's documentation, as one example, says webhooks are especially important for subscriptions because most of the activity happens asynchronously. Renewals, cancellations and failed payments all happen on the billing side, not in a request from your app. Miss those events and you keep serving a customer who cancelled, or lock out one who paid. Whichever provider you use, handle the events, verify they are genuine, and make sure processing the same event twice does no harm.

Store plans as data, not code. A table of plans and the features each one includes lets you change pricing without a release.

Which tech stack should a SaaS product use?

Use the stack your team already knows well, built from widely used parts: a typed language, a relational database such as PostgreSQL, a mainstream web framework and managed hosting. That combination carries most products a long way. The stack matters less than the data model, because a messy framework is easier to replace than tangled tenant data.

Buy what is not your product. Email delivery and file storage exist as managed services, as do error tracking and background jobs, and every one you buy is one less system your team has to run. If the product also needs a public site, our web projects work and our guide on how to make a website for your business cover that side.

What does custom software built around one workflow look like?

We built billing software for a restaurant with a bar that runs late at night. The core requirement was simple: keep bar billing separate from restaurant billing. Staff can now filter bills by time directly, instead of downloading invoices and tracing them by hand, which saves them significant time.

That project is a single-client tool rather than a SaaS product, but the lesson carries over. Its value came from modelling one real workflow precisely, two parts of one business with different hours, rather than from a long feature list. The best early SaaS products tend to start the same way, with one workflow done properly.

When should you refactor a SaaS product?

Refactor when a specific part of the system is slowing you down now: releases in one area keep breaking, a query is too slow for real customers, or a change that should take a day takes a week. Do not refactor because the code looks untidy, or because you might have far more customers one day.

The exception is the three decisions above. If tenant separation, sign-in or billing status is wrong, fix it early, while there are few customers to migrate. Everything else can wait for evidence.

If you are planning a SaaS product, a client portal or an internal tool, our custom software service covers it from scoping to launch. Tell us what you are building and we will start with the decisions that are hardest to undo.