What is a SaaS backend, and which half of it is your product

A SaaS backend is the server-side half of a subscription product: the APIs, the data and the rules that run behind every customer's screen. What makes it a SaaS backend rather than an ordinary web backend is not the language or the database. It is the account model it has to carry - who the user is, which customer they belong to, what they are allowed to do, what they have used, and what they owe at the end of the month.

Microsoft's architecture guidance puts the distinction in one line: SaaS is a business model and multitenancy is an architecture concept. So "SaaS backend" names a backend shaped by a commercial arrangement, not a tier of technology. Most of the pages ranking for this question answer it with a diagram of three layers, data and application and API, and a list of runtimes that would serve a blog equally well. Those layers are real. They are also not the part that takes the time.

Two different things go by this name

The phrase is doing double duty, and the search results mix them freely.

One meaning is the server behind the SaaS product you are building. Your code, your database, your rules, sold to your customers as a subscription.

The other is a backend sold to you as a service: a vendor's hosted auth, data and APIs that you build on instead of standing up yourself. That is a backend-as-a-service, and it is a supplier, not a product category you belong to.

They get conflated because one is routinely built from the other. You can rent a backend as a service and have it be the backend of your SaaS, and plenty of companies do. The test that separates them is who is paying whom. If people pay you to use the thing running on it, you are looking at your SaaS backend, whoever supplies the parts.

The half that is yours, and the half that is everyone's

Here is the claim worth arguing with: in most SaaS products, the backend splits cleanly in two, and the half founders budget for is the smaller one.

The first half is the product. Whatever your customers actually pay for - rendering the image, running the workflow, matching the shifts. It is different in every company, nobody else can write it, and it is the reason the business exists.

The second half is the account model, and it is close to identical everywhere. Somebody signs in. They belong to a company, and that company has members with different levels of access. The company is on a plan, the plan allows some things and not others, usage accrues against an allowance, and at some point an invoice has to be right. Then the product has to tell people what happened, keep a record of who did what, and let an admin undo it.

None of that is differentiating. All of it is load-bearing, and all of it is where the schedule goes. The figure we publish on our own about page is 60-70% of engineering time going to infrastructure rather than product, and we put building sign-in alone at 3-6 weeks before anyone has charged a customer anything.

Sign-in is a good illustration of how the second half quietly grows. Doing it properly now means email and password, magic links, email codes, phone codes through your own provider, passkeys, Google, GitHub, Microsoft, Apple, LinkedIn, a custom OIDC connection, and wallet sign-in for Ethereum and Solana. Every one of those is a week nobody put on the roadmap, and not one of them is why a customer chose you.

What one request has to answer

The clearest way to see the split is to follow a single API call into a SaaS backend. Say a user clicks something in your app and it hits one endpoint.

Before your code does anything interesting, the request has to resolve: is this token valid and unexpired, which session does it belong to, which tenant is the caller acting inside right now, is this member's role allowed to do this, does the tenant's plan include this feature at all, and does it have allowance left this month. Then, and only then, your business logic runs. Afterwards the usage has to be recorded somewhere an invoice can find it, and the whole thing has to land in an audit trail.

Count the steps. One of them is your product.

Each of those answers is also a design decision with a lifespan. Short-lived access tokens with long-lived sessions behind them is one shape - ours are a 2-minute token against a 30-day session, and permission changes propagate on an hourly refresh rather than instantly, which is a real tradeoff and one we had to defend. The point is not that those numbers are correct for you. It is that you will pick a number for each of them, and changing your mind later is a migration.

We run six products of our own on one backend: OnceBooks, PlugNode, AgentCenter, Imejis, RemoteWait and LinkTracer. OnceBooks alone uses fourteen of the twenty modules. The reason that works is not that the products are similar, because they are not. It is that the second half of their backends was always the same, and only the first half ever had to be written again.

When a shared SaaS backend is the wrong choice

An explainer that only lists advantages is a brochure with a dictionary voice, so here are the cases where this shape does not fit.

When the backend is the product. If what you sell is the database, the queue or the inference, then the thing I have been calling "the second half" is your margin and your moat. Buying it is buying your own product from someone else.

When a customer's contract requires their own deployment. Some buyers, particularly in regulated sectors, will not sign unless their data sits in infrastructure nobody else touches. That is a single-tenant install per customer, with its own upgrade schedule, and a shared backend does not get you there.

When you outgrow the deployment. Pooled per-tenant database connections do not scale forever. Roughly 1,000 orgs per deployment is the documented ceiling on ours, and past it the answer is another deployment rather than another config change. Connection pool exhausted as org count grows has the arithmetic. Any backend serving many tenants has a number like this; the useful question to ask a vendor is what theirs is, not whether they have one.

Where this sits next to multi-tenancy

A SaaS backend is the whole server side. Multi-tenancy is the narrower property of serving many customers from one copy of it without letting their data mix, and it is the decision that shapes everything above: which object is the tenant decides what rows belong to whom, what the subscription hangs off, and what the quota counts.

From there the account model fans out into the concepts that have their own pages. Roles and permissions decide what a member may do once you know which tenant they are in. Entitlements decide what their plan includes, which is a different question from what their role allows. Usage-based billing decides what the meter does with the result.

If you want the version with prices attached rather than definitions, the cost of building auth yourself does the arithmetic on one piece of the second half, and the real cost of a multi-vendor stack does it on the bill you end up paying when you buy each piece separately. Best multi-tenant backend covers the options if you have decided to buy rather than build.