Choosing the right backend for a new SaaS build

Reversible and irreversible decisions

Almost everything in a backend can be changed later at moderate cost. You can swap a queue, move a service, change hosting, even change language for one component. These are reversible, and treating them as sacred slows you down for no return.

A short list is not reversible without real pain: how tenancy is modelled, how identity works, and where the source of truth for money lives. We spend our design time there and move fast on everything else.

Decide tenancy before you write anything

Shared database with a tenant column, schema per tenant, or database per tenant — this decision reaches into every query you will ever write. Retrofitting it means touching the entire data layer plus every migration you've shipped.

For most B2B SaaS, a shared database with rigorously enforced tenant scoping is right: cheap to operate, simple to migrate, and adequate until you hit genuine compliance isolation requirements. The trap isn't picking it. The trap is enforcing it by convention, so that one forgotten WHERE clause leaks one customer's data into another's screen. Enforce it at a layer that cannot be forgotten.

Model billing early, build it late

You don't need billing in your first release. You do need a data model that can answer "what is this account entitled to?" and "what have they used?", because bolting those onto a schema that assumed neither is genuinely painful.

Then integrate a provider rather than building an engine. Billing looks simple until you meet proration, tax, dunning, and refunds against a changed plan. That's a product in itself, and it shouldn't be yours.

Start with a monolith you could split

Microservices solve an organisational problem — many teams needing to deploy independently. If you have one team, they add distributed-systems failure modes and buy you nothing.

Build a well-organised monolith with clear internal boundaries. If a component later needs its own scaling or its own team, the boundary is already there to cut along. Splitting a tidy monolith is a normal week's work. Merging premature microservices is not.

The question we ask before all of this

"What breaks first if this succeeds?" If the answer is a specific query, we design for that query. If it's a background job, we design for that job. If nobody can answer, the product is early enough that architecture isn't the risk — shipping is.