When people imagine building a SaaS product, they picture the features their customers will use. Those features matter, but they are often less than half the work. The rest is the platform that lets one team serve many customers safely, reliably and profitably.
We build and operate multi-tenant products of our own, so this is the list we wish every founder saw before their first estimate.
Tenant isolation
Multi-tenant means many customers share one application and, usually, one database. Every query, file, cache entry and background job must be scoped to the right customer. Getting this wrong is the most serious mistake a SaaS product can make, so isolation should be enforced centrally by the platform, not remembered by each developer, and covered by automated tests.
Accounts, roles and authentication
Real organisations have owners, administrators, staff and sometimes their own customers logging in through a portal. You will need invitations, roles and permissions, password resets, multi-factor authentication and, for larger customers, single sign-on with providers such as Microsoft Entra ID, Okta or Google.
Onboarding
A new customer’s first hour decides whether they stay. Good onboarding creates the workspace, sets sensible defaults, imports existing data and shows the product working with their own information as quickly as possible. Sample data and guided set-up are worth building early.
Billing and plans
Subscriptions, trials, plan limits, upgrades, downgrades, failed payments and invoices all need handling, along with what happens to data when a customer leaves. Payment providers handle the money; the product still has to enforce what each plan includes.
Branding and custom domains
Many business products need white-labelling: the customer’s logo, colours and their own domain for a client portal. Custom domains bring certificate management and routing considerations that are much easier to design in from the start.
Background work and integrations
Emails, reminders, imports, reports and integrations with other systems run in the background. They need queues, retries, scheduling and visibility when something fails. Integrations in particular need to cope with the other system being slow, unavailable or changed.
Operational tooling
Someone has to run the product. That means an internal admin area to manage customers and plans, safe impersonation for support (with an audit trail), monitoring and error tracking, backups with tested recovery, and a deployment process that lets you release often without downtime.
Data residency and security
Customers in regulated industries will ask where their data is stored, how it is encrypted and who can access it. For Australian businesses, hosting in an Australian region is increasingly an expectation rather than a differentiator.
| Area | Why it matters early |
|---|---|
| Tenant isolation | Very hard to retrofit safely |
| Roles and permissions | Shapes every screen and API |
| Billing and plan limits | Determines what the product can enforce |
| Custom domains | Affects routing, sessions and certificates |
| Operational tooling | Decides how many people it takes to run |
Start smaller than you think, but not thinner
A first release does not need every feature. It does need the foundations: isolation, authentication, a path to billing and enough operational tooling to support the first customers. Features can be added every week. Foundations are expensive to change once customers depend on them.