The oldest way to sell software is to install it on the customer’s server and invoice a licence. Over the last fifteen years two acronyms have changed that model at the root: SaaS and BaaS. Both are used often and confused just as often. This post puts them side by side: what they mean, how their economics work, and how they change the way a software team works.
SaaS: software as a service
Software as a Service means the software runs on the vendor’s infrastructure and the customer reaches it through a browser or mobile app, by subscription. There is no installation, no version upgrade, no server maintenance; all of that is the vendor’s job. Gmail, Slack, Salesforce and Trello are the best-known examples.
For the customer the meaning is simple: operating expense instead of capital expense, a start in minutes instead of months of installation, always the latest version. For the vendor the meaning runs deeper: one codebase serves hundreds of customers at once, revenue is recurring rather than one-off, and the product is measured while it is live.
Three technical traits define SaaS:
- Multi-tenancy: the same application instance serves several customers; their data is separated by a tenant identifier. One customer seeing another’s data is the fatal error of SaaS, so every query, every file path and every cache key is bound to a tenant.
- Continuous delivery: several small releases a week instead of one “big version” a year. The customer does not update; the update comes to them.
- Usage measurement: who uses which feature how much, which screen is abandoned, which customer will not renew. A SaaS product is managed with data.
BaaS: banking as a service
Banking as a Service means a licensed bank offers its infrastructure, such as account opening, transfers, card issuing and lending, to other companies through APIs. A non-bank company launches a financial product under its own brand; the regulation, the licence and the core system sit with the bank behind it.
An e-commerce site offering “buy now, pay later”, an accounting app that can open a bank account from inside, a retail chain issuing its own branded card: in none of these is the company a bank; there is a BaaS provider behind it. The approach is also called embedded finance: the financial service is embedded in the application the user is already in.
The technical burden of BaaS is heavier than SaaS because the nature of the work is different:
- Regulation: every transaction is subject to audit; know-your-customer, anti-money-laundering, limits and reporting obligations are built into the API’s design.
- Multi-tenancy, one level deeper: the platform serves several banks and, through them, the companies that are those banks’ customers. The tenant hierarchy has two levels.
- Long-lived records: a loan lives for ten years; even a closed account keeps its records for the statutory period. Schema changes must not break history.
The same acronym has a second meaning: Backend as a Service, platforms such as Firebase and Supabase that give mobile and web apps ready-made authentication, database and file storage. Context makes clear which is meant; banking when finance is discussed, backend when app infrastructure is.
Side by side
| SaaS | BaaS | |
|---|---|---|
| What it offers | A ready-to-use application | Banking functions through APIs |
| Who uses it | End users and teams | Companies building products |
| Revenue model | Subscription per user or tenant | Per-transaction fees, volume share, platform licence |
| Critical risk | Tenant data leak, downtime | Regulatory non-compliance, wrong transaction |
| Pace of change | Weekly releases | Controlled releases, backward compatibility mandatory |
| Example | Slack, Supply Management | A bank’s open API platform, embedded cards and loans |
What changes for a software team
In both models the real change is this: software stops being something delivered and becomes something operated. The day-to-day consequences:
- Downtime is not a bug, it is lost revenue. Monitoring, alerting and on-call are part of the product; the answer to “what is happening in production” must be visible on a dashboard.
- Every change must be backward compatible. The customer cannot pick a version; today’s release has to work with yesterday’s data. Database migrations happen in two steps: add first, remove the old later.
- The tenant boundary is everywhere. From authentication to reporting, from file storage to background jobs, every layer asks “which tenant”. If that boundary is not drawn at the start, it cannot be drawn later.
- The product is measured. Feature usage, activation and renewal set development priorities, not intuition.
- Support is part of engineering. One customer’s problem is usually a bug the other hundred have not seen; a support ticket is treated like a good bug report.
Which should a small team choose?
SaaS is a model a small team can carry; that is exactly why we offer Supply Management both in the cloud by subscription and, for organisations that prefer it, on their own server with Docker. One codebase, two deployment forms; tenant separation and configuration-driven behaviour make that possible.
BaaS is the work of an institution, not a team: it needs a licence, capital and a regulatory relationship. Small teams belong in that space either by building products on top of BaaS platforms or by working in the teams that develop them. Most of our banking software experience is of the second kind: developing modules in multi-tenant, regulated, long-lived systems. The discipline learned there turned out to be the most useful thing when designing our own SaaS product.
Summary
SaaS is using software by subscription instead of installing it; BaaS is opening banking infrastructure to others through APIs. What they share is operating software continuously instead of delivering it once. For teams making that shift the issue is habit more than technology: thinking of the tenant in every layer, keeping every change compatible, and measuring the product while it is live.