You have the idea and you can write the app. The part that quietly decides whether Australian enterprises, hospitals, councils and law firms will ever buy from you isn't your feature list — it's where your customers' data lives and who can be compelled to hand it over. Get that wrong and you rebuild your backend the week a procurement questionnaire lands. Get it right on day one and sovereignty becomes a selling point instead of a blocker.
This guide walks through the six layers every SaaS backend needs, the seventh consideration unique to building in Australia, and the fastest way to stand it all up without a US company anywhere in the chain.
The short version
- A SaaS backend is six layers: database, auth, API, storage, email, backups.
- In Australia, data residency & sovereignty sit across all six — and win or lose enterprise deals.
- The Privacy Act 2024 reforms raised the stakes: penalties up to A$50M and a new statutory tort.
- Region ≠ sovereignty. A US provider's Sydney region is still reachable under the US CLOUD Act.
- A sovereign Backend-as-a-Service gives you all six layers, Australian-owned, in days.
The six layers of a modern SaaS backend
Whether you build on Firebase, Supabase, a hand-rolled stack, or a sovereign BaaS, every SaaS product ends up needing the same six things. Understanding them as distinct layers is what lets you make good buy-vs-build decisions.
1. The database
PostgreSQL is the default answer in 2026, and for good reason: it's open-source, battle-tested, relational when you need integrity and JSON-native when you need flexibility, and it has the richest ecosystem of any database. Row-Level Security (RLS) lets you enforce multi-tenant isolation inside the database rather than hoping your application code never leaks a row. Start here — most of the other layers are built directly on top of Postgres.
2. Authentication
Sign-up, login, password reset, email verification, session management, and increasingly SSO and MFA. Rolling your own auth is where security incidents are born. You want managed auth that issues signed JWTs your API and database can trust, so a user's identity flows all the way down to RLS policies.
3. The API layer
Your frontend and integrations need an API over your data. You can hand-write endpoints, or you can auto-generate them: tools like PostgREST turn your Postgres schema and permissions directly into a REST API, and you can layer GraphQL on top. Auto-generated APIs mean you add a column and the endpoint updates itself — no glue code to maintain.
4. File & object storage
User uploads, documents, images, exports. You want S3-compatible object storage so the tooling is standard, with signed URLs so files are access-controlled by the same identity as everything else. For Australian products, where those bytes physically sit matters as much as the database rows.
5. Transactional email
Verification links, password resets, receipts, alerts. This is unglamorous but load-bearing — if your verification email lands in spam, users never activate. You need authenticated sending (SPF, DKIM, DMARC) from a reputable sender, ideally one whose servers are also onshore if you're making a sovereignty claim.
6. Backups & recovery
Automated backups, point-in-time recovery (PITR), and ideally cross-region (or better, cross-state) copies so a single data-centre incident can't erase you. Test your restores — a backup you've never restored is a hope, not a plan.
The seventh layer: sovereignty (this is the Australian part)
Here's what most "how to build a SaaS" guides miss because they're written for a US audience. In Australia, a seventh concern runs across all six layers above: where the data lives, and whose laws reach it.
Two ideas get confused constantly, so let's be precise:
- Data residency is geography — the physical location of the servers. "Our data is in Sydney."
- Data sovereignty is jurisdiction — whose government can legally compel access to the data. This is determined by the provider's corporate ownership, not the server's postcode.
A US company's Sydney region gives you residency, not sovereignty. Under the US CLOUD Act, US authorities can compel a US-incorporated provider to hand over data from any region it operates — without an Australian court ever being involved.
That distinction is the difference between winning and losing deals in health, legal, financial, education, aged care and government. We cover it in depth in Data sovereignty for Australian SaaS, and the specific sector rules in Industries.
What the law actually requires
You don't need to be a lawyer, but you do need to know the shape of your obligations before an enterprise buyer tests them for you.
- You're probably bound by the Privacy Act. You're an "APP entity" if your annual turnover exceeds A$3M — or, regardless of turnover, if you handle health information, trade in personal information, or provide services to other APP entities. Most B2B SaaS is caught by that last one.
- The 2024 reforms raised the stakes. Serious or repeated interference with privacy now carries penalties up to A$50 million, and a new statutory tort gives individuals a direct right of action for serious invasions of privacy.
- APP 8 makes you accountable offshore. It doesn't ban sending personal information overseas, but it makes you liable for what your overseas provider does with it. Keeping data onshore with a sovereign provider removes that risk entirely.
- Some data is localised by law. Consumer Data Right (financial) data, and much health and government data, must stay in Australia. No exceptions to engineer around.
- Procurement will ask. Even where the law is silent, enterprise and government buyers put data residency and sovereignty in their security questionnaires. "We use a US provider's Sydney region" is increasingly a failing answer.
This is general information, not legal advice — but it's the checklist most founders wish they'd had before their first enterprise deal stalled.
Buy vs build: the honest trade-off
You can assemble all seven layers yourself — managed Postgres here, an auth library there, PostgREST, a storage bucket, an email provider, a backup cron — and wire them together. It works, but you now own the integration, the security patching, the on-call, and the job of proving to every customer that no US entity sits in the chain.
The alternative is a Backend-as-a-Service (BaaS): one platform that gives you the database, auth, APIs, storage and email pre-integrated. The catch has always been that the popular ones — Firebase (Google), Supabase (US) — put a US company in your data chain. That's the gap WattleDB was built to close. (More on the options in Firebase alternatives for Australia.)
The sovereign stack, layer by layer
| Layer | What it does | On WattleDB |
|---|---|---|
| Database | Store & query your data | Managed PostgreSQL, kernel-enforced limits, RLS |
| Authentication | Sign-up, login, JWTs | Built-in auth issuing signed JWTs |
| API layer | Expose data to apps | Auto-generated REST & GraphQL |
| Storage | Files & uploads | S3-compatible object storage (AU) |
| Verification, receipts | Transactional email, onshore sending | |
| Backups | Recover from disaster | Automated PITR, cross-state to Melbourne |
| Sovereignty | Whose laws reach the datathe Australian layer | 100% Australian-owned, no CLOUD Act |
A pragmatic launch sequence
- Model your data in Postgres first. Schema, tenants, and RLS policies. Everything else derives from this.
- Turn on auth and wire JWTs into RLS so identity flows from login all the way to the row.
- Expose the API — auto-generate REST/GraphQL rather than hand-writing CRUD endpoints.
- Add storage and email as you need uploads and lifecycle messages.
- Verify backups by doing a restore before you have customers, not after an incident.
- Write your sovereignty story down — where data lives, who owns the provider, what the CLOUD Act exposure is (ideally: none). This becomes your procurement answer.
Where WattleDB fits
WattleDB is Australia's first sovereign Backend-as-a-Service — managed PostgreSQL, auto-generated REST and GraphQL APIs, authentication, S3-compatible storage and transactional email, delivered as one platform on 100% Australian-owned infrastructure in Sydney and Melbourne. It's built by RR Sols Pty Ltd, an Australian company with no foreign parent, so there is no US entity anywhere for the CLOUD Act to compel. Pricing is flat AUD with unmetered bandwidth, so you don't get a surprise egress bill as you grow. That's the seventh layer solved by default, and the other six pre-integrated so you ship in days.