Multi-tenant SaaS, built by people who run their own.
Auth, tenant isolation, billing, admin tooling, deployment and the operational work after launch. We've built this stack for our own products, which is different knowledge from having built it once for a client.
Tenant isolation is where SaaS builds go quietly wrong.
The single most consequential decision in a multi-tenant build is where isolation is enforced, and the most common answer is the wrong one. If a tenant filter lives in application code, you are one forgotten WHERE clause from returning one customer's data to another, and that's a breach, a disclosure obligation and usually a company-ending event for a small SaaS.
The correct answer is enforcement at the database, via row-level security, so a query from one tenant physically cannot return another's rows regardless of what the application layer forgot.
The second thing that goes wrong is billing, which is always harder than it looks, proration, plan changes mid-cycle, failed payments, dunning, usage overages. Teams routinely underestimate it by a factor of three.
The third is that nobody builds admin tooling until support becomes impossible, at which point engineers are running SQL against production to answer customer questions. That's both a security problem and a scaling ceiling.
How it works, step by step.
Decide the tenancy model honestly
Multi-tenant or per-client deployment, based on who your buyers are. Regulated and enterprise customers often want their own instance, and that's a legitimate architecture, not a downgrade.
Enforce isolation at the database
Row-level security policies, verified with real authenticated requests, not with a service key that bypasses them, which is how teams convince themselves it works when it doesn't.
Build auth and roles properly
A real permission model rather than an is_admin boolean, because the boolean always becomes three booleans and then a mess.
Integrate billing early
Subscriptions, usage, proration and failed-payment handling. Retrofitting billing into a live product is materially harder than building it in.
Build admin tooling
So support questions get answered without production SQL access. This is what lets you scale support past the founders.
Set up environments and deployment
Genuine dev, staging and production separation, with a pipeline that runs checks before anything ships.
Four things people assume this is.
Isolation in application code
One missing filter from a breach. It belongs in the database, enforced by policy.
Multi-tenant by default
If your buyers are regulated or enterprise, per-client deployment is often easier to sell and to reason about. We'll ask about your sales motion before assuming.
Billing as a later phase
It always takes three times longer than estimated and is much harder to add to a live product.
A rewrite as the default answer
If you have an existing codebase, the first work is an honest audit. Rewrites are usually the expensive answer to a diagnosable problem.
Concretely, what's delivered.
- Tenant isolation at the database via row-level security, verified with authenticated requests
- Auth and a real permission model, not an admin flag that grows into a mess
- Billing integration, subscriptions, usage, proration, failed payments, dunning
- Admin tooling so support doesn't need production database access
- Environment separation and a deployment pipeline with checks
- Onboarding flow that gets a new tenant to value without a human walking them through it
- Usage instrumentation, so you can see what's actually being used
- Architecture honesty, including when single-tenant is the better call
Why we can say this.
Outlia and Setta are our own multi-tenant SaaS products, running in production with real customers. Row-level security, per-tenant configuration, admin tooling and billing are decisions we've made with our own money at stake.
One thing we learned the hard way and now check everywhere: verify RLS with an authenticated anon-key request, never with a service key. A service key bypasses row-level security entirely, so testing with one will happily confirm that a broken policy works.
What this won't do.
- We're not an enterprise consultancy. If you need a twenty-person delivery team, we're the wrong shape and will say so.
- We won't rebuild from scratch by default. An audit of what exists comes first, and often the answer is repair.
- Compliance certifications are yours to obtain. We build to align with the practices they require; we don't confer them.
- Multi-tenant is not always right, and we'd rather lose a bigger build than sell you the wrong architecture.
Straight answers.
Multi-tenant or one deployment per customer?
Depends on your buyers. Regulated or enterprise customers often want their own instance, and per-client deployment is simpler to reason about security-wise. Multi-tenant is cheaper to operate at volume. We'll walk the trade-off with your actual sales motion in mind rather than defaulting.
How do you handle tenant data isolation?
Row-level security at the database, so a query from one tenant physically cannot return another's rows. Application-layer filtering alone is one forgotten clause away from a breach. And we verify with authenticated requests, because a service key bypasses RLS and will falsely confirm a broken policy.
Can you take over an existing SaaS codebase?
Yes, and it's common. The first work is an honest audit before anyone promises a timeline or proposes a rewrite.
What about billing?
Stripe, typically, with subscriptions, usage-based components, proration and dunning. It's consistently underestimated and we scope it as real work rather than a week at the end.
Do you do ongoing maintenance?
On a retainer, or we hand over with documentation. Both are genuinely available, we're not trying to build dependency.
How fast can you ship a v1?
A focused first version in four to eight weeks depending on scope. We'd rather launch one workflow properly than five half-built.
Anqor is a small studio, so you deal with the person who builds it. If this isn't the right fit for your business, I'd rather say so on the first call than sell you something you don't need.
LinkedIn →Bring your architecture. We'll audit it honestly.
If it's sound we'll tell you. If isolation is enforced in the wrong layer, you want to know now rather than after a disclosure.