DEV Community: Supero

AI app builders and multi-tenant SaaS: the 30% you still write yourself

Srikanth Reddy Kasa — Fri, 02 Oct 2026 16:49:41 +0000

Written for: developers who built something real with Lovable, Bolt or v0 and are now being asked to make it multi-tenant.

This is Part 2 of The Last 30% — a series about the part of an app you still write yourself. Part 1 was about Supabase RLS: it protects rows, and Postgres's answer for columns — grants — is per database role rather than per JWT claim, which is where it stops fitting. This one is the same argument one altitude up. Part 1 asked what the database doesn't cover. Part 2 asks what generation doesn't produce at all.

The short version: AI app builders are excellent at code with high pattern density and local correctness — a component, a form, a schema, a page. They are weak at properties that are global: authorization, multi-tenant isolation, compensating transactions, idempotency, and audit. Generation is local. Invariants are global. That mismatch is the entire gap, and it is invisible in a working demo — which is why nobody catches it until the second customer, or the first refund.

(Disclosure: I work on Supero, which is in this category and splits the problem differently. There is a section below on where these tools beat us, because a comparison that claims a clean sweep isn't worth your time.)

Type a prompt into Lovable, Bolt or v0 and ninety seconds later you have a working app. Real React, sensible components, a layout better than most of us produce by hand, deployed to a URL you can send to someone. The reflexive engineer dismissal of that is wrong, and this post isn't it.

Why some code generates beautifully

Generation works spectacularly on things with high pattern density and local correctness:

A React component. Thousands of examples in training, obvious success criteria, and wrong is visibly wrong.
A CRUD form. Even more examples.
A landing page. The model has seen a million.
A schema for a blog. There is almost a canonical answer.

What those share is a property worth naming, because it's the whole mechanism: you can look at the output and tell whether it's right. Tight feedback loop, local correctness, and 95% is fine — because the last 5% is visible and quick to fix.

Here is the shape of handler you get. Not a strawman; this is good code:

@app.get("/invoices")
def list_invoices(db: Session = Depends(get_db)):
    return (db.query(Invoice)
              .order_by(Invoice.created_at.desc())
              .limit(50)
              .all())

Readable, typed, paginated, correct ordering. Reviewed on its own it passes. The problem only exists in relation to code that isn't on screen: there's no tenant predicate, and you cannot see that from here. You can only see it by knowing what every other handler in the app does.

Add the predicate and the local problem goes away:

@app.get("/invoices")
def list_invoices(db: Session = Depends(get_db), claims = Depends(auth)):
    return (db.query(Invoice)
              .filter(Invoice.tenant_id == claims.tenant_id)   # <-- the whole ballgame
              .order_by(Invoice.created_at.desc())
              .limit(50)
              .all())

Now notice what you actually bought. Not isolation — one isolated endpoint. Isolation is only true if that line is true of every query, including the one written six months from now by someone who read none of the first fifty. That's a global property, and no amount of per-prompt generation produces one.

The list of things that don't generate, and why it's always the same list

The gap	Why generation misses it
Authorization	Not login — login is a form and a token, and generates fine. Authorization is who may see which rows and fields, under which conditions, and it's a property of your whole query surface. Globally correct, or not correct at all.
Multi-tenant isolation	True only if true of every query ever written against the schema.
Compensating transactions	The charge succeeded; the order insert failed. What reverses it? Often a surprising amount of code, exercised only in failure, with no visual signal when it's absent.
State machines that refuse	`refunded → paid` should be a `409` and an unchanged record. The generated answer is usually an `UPDATE`.
Idempotency	The network retried. Did the customer get charged twice? Nothing in the output tells you.
Audit	Not "do you log" — can you answer, in six months, who accessed this record.

Every one of those is invisible in a working demo. They're properties of the system under failure, under adversarial use, or under time. You cannot look at the screen and see that compensation is missing. That's the difference between the two columns:

" width="799" height="434">

On the number: "70/30" is my estimate from watching teams take generated apps to production, not a measured statistic, and I'd rather label it than have it quoted back as one. The proportion is arguable. The kind of thing in the right-hand column is not, and the kind is the point.

Credit where it's due: one of those six gets real attention

"They skip authorization" would be a tidy line for me to write and it isn't accurate, so I'm not writing it.

Lovable runs a Quick scan automatically every time the publish dialog opens: it checks your database access rules and flags tables with no row-level security and rules that let everyone through. A separate Deep scan reviews your application code — including server code that bypasses the rules your database enforces — but it does not run in that dialog; you trigger it from the Security view. Both are free on every plan, and a workspace can switch on a setting that blocks publishing while critical findings are unresolved. That is a shipped feature and it is more than most of this category ships. Lovable also creates RLS policies itself when it builds a feature that stores user data. Its own documentation is candid about the ceiling — these tools "cannot guarantee complete security" — and recommends a professional review for anything sensitive.

Two things remain true, and they're more interesting than the tidy line:

The policy a builder reaches for by default is per-row ownership, not tenant isolation. user_id = auth.uid() is not a tenant boundary. RLS can express organisation membership — Part 1 opens with a policy that does, and calls it a real security boundary. What it can't do is guarantee that the org-scoped version, rather than the owner-scoped one, is what got written on every table — including the table added after the prompt that created the first fifty. And it says nothing at all about a client holding a service-role key that bypasses every policy you wrote.
Completeness is tooled. Correctness is not. A scanner can tell you which tables have no rule — Lovable's publish scan does, and so does Supabase's Security Advisor, and you should use both. What no scanner tells you is whether the rule you wrote expresses your model: that user_id = auth.uid() is the right predicate for an org-scoped app, that a tenant-scoped role is honoured, and that the application layer above re-derives the same decision. The disclosure behind the CVE below says precisely this about Lovable's publish check — it "will help ensure that RLS policies are enabled in all tables and notify if they aren't (but doesn't necessarily indicate if they are sufficient)". Table-level completeness is tooled. Semantic correctness across your whole query surface is the part you still own.

The CVE, stated precisely

The stakes here are documented rather than hypothetical — but the record needs quoting exactly, because the imprecise version of this story is everywhere and it's unfair.

CVE-2025-48757. CVSS 3.1 base score 9.3 CRITICAL, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N — assigned by the CNA and carried in the NVD record as a Secondary metric. NVD itself has published no score: vulnStatus is Deferred, meaning NVD will not analyse the entry. Published 2025-05-30, last modified 2026-06-17. NVD's description, verbatim:

An insufficient database Row-Level Security policy in Lovable through 2025-04-15 allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites. NOTE: this is disputed by the Supplier because each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application.

Five things you should take from that, in order:

It is bounded in the past. The affected range stops at 2025-04-15, and the entry marks every other version unknown rather than affected. Exploitation required the project to be using an external database as its backend. Nothing here says anything about Lovable's security today, and I'm not implying it.
Provenance, because precision cuts both ways. The finding was disclosed by Matt Palmer at Replit, Inc. — a Lovable competitor, as am I. His own submitted vector was scope-unchanged and scored 8.26, not the 9.3 the CNA filed. Lovable acknowledged it in three days and shipped a patch on 2025-04-24, five weeks before public disclosure. Every one of those facts cuts against the scary version of this story, and all three are in the record.
NVD carries it with a disputed tag (alongside exclusively-hosted-service), with vulnStatus: Deferred. The supplier's position is in the quote: each customer accepts responsibility for protecting their own application's data. You can agree or disagree with that division of responsibility — I'd just rather you read it than take my summary of it.
The widely-quoted "170+ affected apps" is the disclosing researcher's scan, not Lovable's figure, and I have not independently reproduced it. If you cite it, cite it that way. Two fields in the same entry carry more weight than any count: it is classified CWE-863, Incorrect Authorization — the taxonomy's own name for this layer — and the CISA Coordinator's SSVC assessment records exploitation: proof-of-concept, automatable: yes, technical impact: partial.
The reason to mention a disputed, historical CVE at all is that it is the clearest public evidence of where generated apps break. Not in the components. In the layer that has to be globally true. Lovable is also the only one of the three with a public entry of this kind, and that is not evidence it is the weakest — it is evidence that someone looked, told the vendor, and wrote it down, which is more than exists for the other two. Read the asymmetry as a gap in the public record, not as a ranking.

Four tests, about an hour, useful regardless of what you build on

This is the part I'd actually do before the next planning meeting. None of it involves me or my product.

**1. Be the second tenant. Create two orgs, two users. Use a domain you control for the fixtures, and reserved-for-fiction phone numbers (US 555-0100 to 555-0199, UK 020 7946 0xxx) — if a list or export route does return 200 when it shouldn't, you don't want it reaching a real person. With tenant A's token, request a record id owned by tenant B:

curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer $TENANT_A_TOKEN" \
  https://your-app.example/api/invoices/$ID_OWNED_BY_TENANT_B

403 or 404 is right. 200 is the whole post. Then do it again on a list endpoint with a filter parameter, and again on whatever search or export route exists — those are the ones that get added later and miss the predicate.

Then check the paths that don't go through the API at all. An uploaded file often sits in storage behind a URL of its own, so a route can return a clean 403 while the object is fetchable beside it — request tenant B's file by its URL directly. Same for background work: exports, scheduled emails and webhook handlers usually run with a service key and no signed-in user, so the tenant has to come from the job's own data. Trigger an export as tenant A and read what lands in the file.

2. Break a payment in the middle. Do tests 2 and 3 in your payment provider's test mode, with test keys, against a staging tenant — the point is to see the state you're left in, not to move real money. Make the write after the charge fail, on purpose:

charge = payments.create(amount=4900, currency="usd")   # succeeds
raise RuntimeError("simulated failure after the charge")
db.add(Order(id=order_id, charge_id=charge.id))         # never runs
db.commit()                                             # never runs

Money moved; no order exists. Now go look for the code that reverses the charge. If you can't find it in under two minutes, it isn't there — and it is often a surprising amount of code, enough that teams defer it.

3. Retry a charge. Fire the same mutation twice and compare:

for i in 1 2; do
  curl -s -X POST https://your-app.example/api/orders/42/capture \
       -H "Authorization: Bearer $TOKEN" \
       -o /dev/null -w "attempt $i -> %{http_code}\n"
done

Then check the payment provider's dashboard for two charges. Two 200s and one charge is fine (something short-circuited). Two 200s and two charges is a bug with a customer attached to it. While you're there, set an order to refunded and POST the pay transition — you want a 409 and a record that didn't move.

4. Ask the audit question. Not "do we log" — run the actual query a security reviewer will ask you for:

select actor, action, occurred_at
from audit_log
where record_type = 'invoice'
  and record_id = $1
  and action = 'read'
order by occurred_at desc;

If that returns zero rows because nothing ever wrote a read event, you have write-side audit only. That's worth knowing in advance of the conversation rather than during it. (Keep reading — so do we.)

The three ways teams handle the 30%

Write it yourself. Correct, and it's the part that takes most of the time — on a codebase you didn't design, whose conventions you're inferring as you go.

Ship without it. Extremely common, and genuinely fine until it isn't. Internal tools and prototypes do not need compensating transactions. The problem is that prototypes get promoted, and nobody ever schedules the sprint where the prototype becomes a product.

Put it in the platform. Don't generate the invariants — inherit them. Generate what generates well, and let the rest be a structural property of the thing your app runs on.

How we split it, including the rows I'd rather not print

Supero generates the same layer everyone generates: data model, CRUD REST API, a generated client library, OpenAPI docs, admin console, customer web UI, deployed and running. Be precise about that client library, because our own API reference is: it is not typed. The reference says in as many words that the generated client documents your fields and gives you no compile-time or editor-time checking of them — a misspelled type name is still a runtime failure. Python is the one you can actually install (supero, on PyPI, and its own classifier says beta). The JavaScript package our docs tell you to npm install is not published, so that command 404s today. Go and Java are registry stubs, and the failure mode is the one this whole post is about: ask for java and you get 202 queued and then a Python and a JavaScript artifact, with nothing in the response marking the language as unavailable. The rest is underneath, not generated:

The invisible part	How it's provided
Tenant isolation	Structural, on the path that matters: for CRUD reads the tenant is derived from the authenticated principal in exactly one function, and a CI gate fails the build if any read path stops delegating to it. That covers the API your app and your users go through. It does not cover background work — scheduled jobs, webhook handlers and connector runs authenticate as a system identity that sits above the tenant boundary, the same way a service role key does, and where they act on one tenant it travels as job data. Our own published multi-tenant checklist scores that honestly and I'll borrow its words — a developer cannot leak by forgetting, and can leak by being provisioned wrong. Two documented ways: the admin tier has standing exemptions, and anyone left in the auto-created `default-tenant` gets project-wide read across every other tenant in that project, whatever their role — so a real customer must never be put there. On a connected external source the binding is per table, and it's worse than configuration you can get wrong: a live table created through the console's wizard is always saved with a `fixed` tenant binding whatever you type into the tenant-routing panel, and a fixed binding does no per-row filtering at all. The policy layer sitting on top of all that is not deny-by-default: an entity with no access policy gets full create, read, update and delete rather than a refusal. Deny-by-default isn't a switch we ship — it's something you build, an access policy per role with `default_access: "none"` plus a rule per entity you want to allow — and that object policy is evaluated on writes: it is not consulted on a read, so setting an entity to `"none"` stops a role writing it and leaves the records readable. Separately, our platform-, domain- and project-admin roles bypass access policies outright, and that tier includes project-scoped API keys, not just human super-admins — so a key you mint for your own integration is not constrained by the policy layer. The tenant admin inside your app does not bypass. Part 1 carried the same admission.
Field permissions	A field a caller can't see can't be `distinct`-ed, grouped by or aggregated over, including via a raw pipeline — enforced on the query path, not only on the response, and asserted end to end by `test_53_access_policy_e2e`. Sort and filter are a different story, and the honest version is worse than the hedge I had here before: they're guarded on a live external source, and on our own storage they are not. The guard that would refuse them is deployed in monitor mode — it records that it would have denied the read, then returns the rows anyway — so an `order_by` on a hidden field gets you a `200` and the argmax row. That's published in full, with the request that demonstrates it, and it's Part 3 of this series: permissions that leak through `ORDER BY`. The response-side strip is defence in depth, not the strong half: it falls through on a policy-resolution failure, a missing session context, an empty policy and an unexpected error, and credential-shaped fields are held back by a separate hard-coded denylist rather than by the policy engine.
Role escalation	Custom roles carry a permission ceiling: they can't shadow a builtin, exceed the creator's base, or forge `is_builtin`.
Compensation	A saga orchestrator — step 4 fails, steps 3, 2, 1 reverse, as platform code rather than yours. Reversal depends on each operation declaring a correct inverse, and fourteen of ours are currently mis-declared. When an inverse can't be built the walker refuses to fire it and stops — which abandons the reversal of every earlier step in that saga too, not just the one. We found them because the suite that was supposed to cover them had been exercising its own fixture rather than the real manifests. Ask us which operations are affected before you build a money path on one.
Invalid transitions	State machines return `409` and leave the record alone.
Idempotency	A state-guarded transition refuses an out-of-state repeat, so a retry doesn't write the record twice. Two things it is not: we are not the payment processor — we record the charge your app made at Stripe or PayPal, so a duplicate charge is prevented by the idempotency key you send them, not by us; and the guard is read-then-write with no lock, so two genuinely concurrent retries can both pass it. Cumulative operations like partial refunds need your own key either way.
Audit	Write-side only. We can tell you who wrote a record. We cannot tell you who read one. And check the plan before you count on even that half: the audit log is bundled from Pro up and is a $49/mo add-on below that, so on a free or entry plan it isn't write-side-only, it's absent.

Several of those rows are admissions, not features, and they are the ones I'd raise first rather than a complete list. Audit is on my own list of six, so leaving it out of our own table would have made this post a sales page — it's the gap I'd raise first if I were evaluating us, and test 4 above will find it. Permissive-by-default access is the other, and the test for it is not test 1. Test 1 is the one the shared data layer is built to pass, which is exactly why it won't show you this: run it and you get a clean 403. (Not a flawless pass either — see the default-tenant and admin-exemption admissions in the isolation row above.) Create a second non-admin user inside your own tenant, leave an entity with no access policy, and try to list, edit and delete a row belonging to the first user. Ours returns the row and lets you write it. I'd rather you hit both here than after signing something.

The fine print, since you'd find it anyway: connector write-back in place runs only in live read-write mode, it is implemented for Postgres (Supabase included) and MySQL, and it is validated end to end on Postgres only — our own supported-sources matrix says MySQL live write-through has not been verified end to end, so don't take my word for it in either direction. In sync mode a connector is a copy: an edit on our side returns a 200 and never reaches your database. There is a signal — we stamp an access_mode on the response — but it is per connector, not per table, and when one connector mixes modes the most permissive one wins, so that stamp can read live-rw for a write that actually landed in our local copy. We're designed for SOC 2 controls — not certified against SOC 2, ISO 27001 or PCI DSS. On HIPAA, read our compliance page rather than my summary: no Business Associate Agreement is offered, and that page tells you in as many words not to put protected health information into Supero Cloud on the strength of it. Read audit is the control a HIPAA reviewer asks about first, which is precisely the row above. Custom domains: the code is built but dark, and our published position is blunter than that — there is no self-service flow on any deployment target, no DNS automation and no certificate provisioning anywhere in the deploy path, we publish no timeline, and the $25/project/month custom-domain line in our own catalog does not enable one if you buy it. A scheduled connector sync you can configure and save, and it validates — but whether the runner actually fires it depends on the deployment, so confirm a real run in Run History before you depend on one. And our source export is one-way, in the two senses spelled out below.

The distinction that actually matters: the platform provides these; the prompt does not emit them. They aren't better-generated code. They're code written once, by people, tested adversarially, that your generated app runs on top of.

Where Lovable, Bolt and v0 beat us

Visual quality. They're better. The design-first builders produce interfaces that look considered; ours look like competent conventional software. If the interface is the product, use them.

Speed of first result. Theirs is seconds — a sign-up and a free token budget, no access request. Ours is a free signup (no card) and then under a minute to a few minutes. The deployment story is the real gap, and it deserves stating in the direction that's fair to both sides: our free plan does hand you a public preview URL, but it's reaped after about thirty minutes, and a deployment that stays up starts at $9.99/mo (listed at $19.99, currently half off) where theirs is a public URL on the free plan. That is a real disadvantage when someone is evaluating three tools on a Thursday afternoon.

Iteration feel. The prompt-see-adjust loop on a UI is tight and pleasant in a way that generation over a governed backend is not.

Code you own from second one. All three say you own the code they generate — read each one's terms, they word it differently — and their access models differ in ways worth knowing:

Bolt has the most straightforward path: project title → Export → Download hands you a .zip of your project files — code, not the database or your environment variables. Its docs state no plan requirement for it, which is worth noting because the same docs do say custom domains and bringing your own Supabase are paid-only. Its GitHub integration also runs both ways: it auto-commits your changes and polls GitHub every 30 seconds for commits made outside Bolt (its docs note Bolt's copy wins a simultaneous-edit conflict).
Lovable gates full codebase download to paid plans, but Git sync is a genuine two-way sync to a repo you own on GitHub, GitLab (including a self-managed instance) or Bitbucket, on any plan, with GitHub Enterprise Cloud/Server on the Enterprise plan. It exports from Lovable; it won't import an existing repo.
v0 doesn't need a repository at all — Vercel's docs say Git integration is optional, and projects without GitHub deploy their current code straight to Vercel. Connect one and v0 creates a private repo in an account or org you choose, and that sync is bi-directional. Publishing goes to Vercel, though the docs say you can export the code and deploy elsewhere.

Check each one's current docs before you rely on any of that. It's the fastest-moving column in the comparison and any of it may have changed since the date at the bottom of this post. None of the three is relationship-free, but the defaults are not what the lazy version of this sentence says: Bolt's default home is its own Cloud (.bolt.host plus a Bolt database on every plan; Netlify is the documented alternative, and using your own Supabase account needs a paid plan), Lovable now ships its own managed Postgres with Supabase as an optional connection, and v0 publishes to Vercel though its docs say you can export and host elsewhere.

Their code access is more open than ours in two ways, not one. Bolt's and Lovable's and v0's Git syncs all run both directions where our export is one-way — you get the code, your edits to it don't come back. And their output runs on its own where ours doesn't: the code we hand you proxies its /api/* calls back to Supero, so it needs Supero behind it — our cloud, or your own AWS or GCP account where the UI is yours and the backend still calls us, or a licensed install on your own servers, which is an Enterprise arrangement we have not yet published a customer runbook for. Worth saying plainly — the tightest coupling in this comparison is ours. If walking away with a standalone codebase is the requirement, they win that outright.

The use-case split, stated plainly: marketing site, landing page, design-led consumer app, or a prototype for an investor next week — use them. That's the correct recommendation and we'd be the worse tool for it.

When the 30% starts to matter

It isn't a size threshold. It's a set of events:

A second customer organisation logs in, and neither may see the other.
Money moves, so a half-applied sequence becomes a reconciliation problem instead of a bug.
A customer's security review asks how field permissions are enforced.
Regulated data arrives — anything where a histogram is a leak.
A second developer joins, and invariants stop being enforced by one person's memory.

Before the first of those, this post is a distraction. After it, retrofitting means auditing every query path and then installing a mechanism that makes the next one safe. That is expensive, and it is the one piece of work you cannot do file by file in isolation — but it is a refactor with a checklist, not a rewrite. Part 1's audit query is the Supabase-shaped version of that checklist.

FAQ

Can Lovable or Bolt build a multi-tenant SaaS?
They can generate the pieces, including Supabase RLS policies, and Lovable's publish scan will tell you which tables ended up with no rule at all. What's missing is anything that checks the rules you got express your tenancy model across the whole query surface.

Is Bolt or Lovable production ready?
For the frontend, and for single-tenant apps, frequently yes. The question to ask isn't about code quality — it's about the invariants: isolation, compensation, idempotency, audit.

What does an AI app builder not generate?
Anything globally correct rather than locally correct: authorization across the whole query surface, tenant isolation, compensating transactions, idempotency, and read audit.

Can I use an AI builder for the frontend and something else for the backend?
Yes, and it's a sensible split: generate the UI where generation is strongest, and put the invariants in a layer that enforces them for every query.

How do I test for the missing 30%?
The four tests above. Fail a step in the middle of a payment flow and see what state you're left in; retry a charge and check for a double; log in as a second tenant and try to read the first; run the read-audit query.

Part 3, which is already published

Part 3 goes after the leak itself: how field permissions escape through ORDER BY and aggregates — queries that are individually correct, return no hidden field, pass review, and still let a caller binary-search a value they were never allowed to see. It's up, and it includes the request that demonstrates the gap against our own storage: Your field-level permissions probably leak through ORDER BY. If you ran test 1 above and got clean 403s, that's the test that will surprise you.

What to do next

Audit your generated app against the table above. Six rows, an afternoon, and it's useful regardless of what you end up building on. Nothing in it requires talking to me.

Then, if you want to see what the other approach produces, applications generated by the platform are live and need no account — sixteen at the time of writing, with the current list at api.supero.dev/api/v1/public/showcase: concierge.supero.live · atelier.supero.live · ledgerline.supero.live. Two fair warnings. They scale to zero, so the first load is waking a cold container — give it ten seconds or so, and an idle one occasionally won't wake on the first try. And most are single-tenant public demos — they show you the generated application, the data model and the screens, not the governance this post argues about.

One exception is worth your time. sentinel.supero.live runs two insurers on one deployment — Northwind Mutual and Cascade Assurance — with four published logins across both tenants, so you can run test 1 against us directly. The two tenants use different claim-number prefixes, so a leak would be visible on sight. Same cold start as the others, so give the first page a few seconds. The login page hands you a working, shared, writable account, so treat anything you create there as public.

And if you'd rather read the output than click through it, the reference apps are on GitHub — MIT-licensed, readable Python and JS, nineteen of them: github.com/supero-platform/supero-apps. That's the honest test of the first half of this post: the generated layer is real code you can inspect in a browser tab. What you won't see in that repo is the part this whole piece is about — the invariants don't live in the generated files, which is rather the point.

Start free if the generated output is the standard you'd ship. One number the pricing page doesn't print, and you'll want it before you judge us on output: the free plan's budget is three app generations a month.

Lovable, Bolt and v0 capabilities checked 2 October 2026 against each vendor's own documentation — docs.lovable.dev/features/security, docs.lovable.dev/integrations/git-sync-overview, support.bolt.new and v0.app/docs (v0's pages are stamped 1 October 2026); CVE data from the NVD API the same day. This category changes monthly — if something here is out of date or wrong, tell me in the comments and I'll correct it. A comparison with an error in it is worse than no comparison.

Supabase RLS is great. Here's the part you'll still build yourself.

Srikanth Reddy Kasa — Mon, 28 Sep 2026 17:30:04 +0000

If you're building multi-tenant SaaS on Supabase, you probably picked it for one very good reason: Row Level Security. And you were right to.

create policy tenant_isolation on orders
  for all to authenticated
  using (org_id = ((select auth.jwt()) -> 'app_metadata' ->> 'org_id')::uuid);

That policy is a real security boundary. Postgres appends it whether or not you remembered a WHERE — and it holds the same for PostgREST, the JS client, a psql session, and a 3 a.m. background job. That's categorically stronger than filtering in an ORM, and it's the single best reason to build multi-tenant SaaS on Supabase.

I'm not going to argue with any of that. I'm going to point at the four things it doesn't cover — because you'll meet all four eventually, and it's better to meet them now than in month nine.

(Full disclosure: I work on Supero, which competes with Supabase (https://www.supero.dev/?utm_source=devto&utm_campaign=vs-supabase). This is a critique of a structural property of RLS, not of Supabase's implementation, which is genuinely good.)

1. RLS answers "which rows." Not "which columns, for whom."

RLS is row-level. It says nothing about columns. Postgres does have an answer for columns — grants:

revoke select (salary) on employee from authenticated;
grant  select (id, name, dept) on employee to authenticated;

Those are checked against every column your query touches — including ORDER BY. But they're per database role, not per JWT claim. So the moment your requirement becomes "managers see salary, staff don't, and both log in as authenticated," grants stop fitting. You reach for a view per audience:

create view employee_staff with (security_invoker = true) as
  select id, name, dept from employee;

Views work. They also multiply — one per audience per table, each needing maintenance every time the base table changes. Everyone who's done this remembers the migration where they added a column and found seven views to update, and missed one.

The part worth stating precisely (because it's easy to get wrong in my favour): if you hide salary with a column grant or a restricted view, this is blocked —

GET /employee?select=name&order=salary.desc&limit=1

Postgres refuses it. A competent Supabase team using grants or views has already closed this.

The leak shows up when you mask fields in your own API layer instead — a Next.js route that fetches the row and deletes salary from the JSON before returning it. That's extremely common once JWT-based, per-tenant logic arrives. And at that point the sort/filter surface is ungoverned again: order=salary.desc returns the top earner's name without a salary, and ?salary=gt.200000 with Prefer: count=exact becomes an oracle that binary-searches the value. (On Supabase specifically, distinct and aggregates are off by default, so two of those vectors need someone to have turned them on.)

So the criticism isn't "RLS leaks." It's that RLS protects what stays at the database boundary — and most teams eventually stop staying there.

2. Every policy is a policy someone has to remember to write

RLS is opt-in per table. Credit where due: tables created in the Table Editor get it on by default. But tables created by a migration don't — alter table … enable row level security is a line a human types. At sixty tables, over two years, with a rotating team, the failure mode is a missing policy on the table someone added last Tuesday.

Supabase does back you up here — its Security Advisor flags a public table with RLS disabled as an error. That's a good backstop; I wouldn't build without it. Two things that get less airtime:

Table owners bypass RLS unless you set alter table … force row level security. If migrations run as the owner and something reuses that role, your policies simply don't apply.
You can audit it in one query and fail CI on the result:

select c.relname, c.relrowsecurity as rls_enabled,
       c.relforcerowsecurity as rls_forced, count(p.polname) as policies
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
left join pg_policy p on p.polrelid = c.oid
where n.nspname = 'public' and c.relkind = 'r'
group by 1,2,3
having c.relrowsecurity is false or count(p.polname) = 0;

But notice what that combination is: isolation as your team's discipline plus a linter, rather than as the architecture. Better than nothing. Weaker than structural.

3. `service_role` bypasses all of it

The most common real-world Supabase multi-tenant failure isn't a missing policy. It's the service_role key — which bypasses RLS entirely — leaking into a client bundle, or getting used in an edge function because threading the user's JWT through was more work.

RLS is a strong boundary with a documented master key. Whether that key stays server-side is a property of your team's process, not of the database. Rotate it, never ship it to a client, and grep your repo for it before you read on.

4. Sub-tenancy gets awkward fast

A flat org_id claim handles "customer A can't see customer B." The next asks are harder: a customer with two divisions; a reseller who needs a view across fifteen customers; a user who belongs to two orgs and switches.

Each is doable — a recursive CTE over an org tree in the policy, a claims array, a SECURITY DEFINER helper. But now your isolation predicate is a non-trivial function evaluated on every row of every query — a correctness surface and a performance surface. Supabase has published the performance fix (wrap auth.uid() in a scalar subselect so it runs once; index the column), and it works. It's still one more thing you maintain.

The honest turn

Here's the objection this whole post has been arming you with: if the leak lives in the application layer, and Supero is an application layer, why not just use column grants and a view per audience?

For a two-audience system — honestly, do that. It's free, it's older than both of us, and this post showed you how.

The argument only starts paying when your audiences stop being database roles. The moment visibility depends on a JWT claim — this manager, this tenant, this customer's own staff — column grants don't fit, because they're per-role and every logged-in user shares one role. That's the point where every team ends up building an application layer anyway. And the only question left is whether the "can this caller see this field" decision is computed once and applied to both the response and the query surface, or computed twice and allowed to drift.

That's the whole of what Supero does differently: one field decision, two enforcement points (the response and what you can sort, filter, group, or aggregate by), assembled below your app across four levels — domain → project → tenant → user — with no per-table enable step to forget.

And I'll be straight about where we're not there yet, because a comparison page that hides its own gaps isn't worth reading: our access policy is permissive by default, so entities need explicit policies and generated apps can ship without them; the admin tier bypasses access policies entirely; we log who wrote a record but not who read one; and order_by/filter on a hidden field aren't yet guarded on our own storage (they are on a live external DB). If those are dealbreakers, better you know now.

Where Supabase simply wins

Open source and self-hostable — a stronger, more proven position than ours. If that's your top criterion, the comparison is over.
It's Postgres — every extension, tool, DBA, and Stack Overflow answer of the last fifteen years.
Maturity and ecosystem at a scale we don't have.
Direct SQL — the full expressive power of the database. We give you a query builder and an API; for many engineers that's a downgrade, and it's a fair objection.

What to actually do next

Run the audit query from §2 against your own database. If it returns rows, that's today's work — and it has nothing to do with me.

If you then want to see what a generated, governed app looks like, sixteen of ours are live and need no account: concierge.supero.live · atelier.supero.live · ledgerline.supero.live. Fair warning: those are single-tenant public demos with no hidden-field policies configured, so they show you the generated application — the model, the screens, the finish — not the field enforcement this post argues about. Pointing the order= test at them returns 200 because there's nothing there to refuse; that proves nothing either way.

The example apps are also on GitHub — MIT-licensed, readable Python and JS you can inspect: https://github.com/supero-platform/supero-apps

To see the enforcement itself, come find me — I'll run the aggregate vectors against a schema with a real hidden field. Thirty minutes with an engineer, not a demo.

If anything here is wrong about Supabase, tell me and I'll fix it — a comparison with an error in it is worse than no comparison.

What Supero doesn't do yet - the honest list!

Srikanth Reddy Kasa — Tue, 22 Sep 2026 14:42:43 +0000

Most product updates focus on new features and what's working well. This one is about the other side: what Supero doesn't support yet.

For transparency, I work on Supero, a platform for generating governed, multi-tenant applications from a schema. These are the limitations I’d want to understand before choosing a platform like ours.

Database connectors:

Supero can read from external databases. Direct write-back currently works with Postgres, Supabase and MySQL.

One way sync, which would copy source data into the application on a schedule, isn't available yet either. It's on the roadmap.

It's also worth being clear about what we mean by one way sync. It copies source data into the application, but it doesn't reconcile records deleted from the source or push local changes back upstream.

Access policies:

Access policies need to be configured. Creating an entity without attaching a policy doesn't automatically lock it down, and the admin role is intentionally powerful.

That gives developers control over the policy model, but it also means you need to review the generated policies instead of assuming everything is denied by default. Deny-by-default scaffolding is something we want to add, but it isn't the current behavior.

Audit history:

We track who created or changed a record. We don't yet track who viewed it.

If your compliance requirements include read-access history, you will need to cover that separately for now.

SLA and mobile:

We have web applications running in production, but we don't publish an uptime SLA yet.

Mobile also hasn’t had the same level of real-world use and testing as web. If mobile support or a formal SLA is essential to your application, talk to us before building around it.

Free trial:

You can use the free tier to generate an application and test it end to end without entering a card.

It's meant for evaluation, though. Keeping an application hosted permanently requires a paid plan.

What you can test today:

The areas we are comfortable asking developers to test closely are tenant and role isolation enforced on the server, and field-level access that removes restricted fields from the API response rather than only hiding them in the UI.

You also own the generated code. The applications use readable Python and JavaScript, and you can download them, move them to your own repository and run them on Supero Cloud, AWS, GCP or your own infrastructure.

Our demos include test credentials and curl commands because we would rather let you test the access controls yourself than simply claim they work.

If one of these limitations blocks your use case, let us know. That feedback helps us decide what to work on next. If you find another gap that isn't listed here, we would like to know about that too.

Code and demo apps 19 MIT-licensed projects:

https://github.com/supero-platform/supero-apps

Try the builder:
https://supero.dev/?utm_source=devto&utm_medium=post&utm_campaign=honest-list

The multi-tenant SaaS checklist: six decisions to make now, one to ignore

Srikanth Reddy Kasa — Tue, 15 Sep 2026 07:24:21 +0000

The multi-tenant SaaS checklist: seven decisions, what each costs if you defer it, and the one everyone worries about far too early.

Overview

#	Decision	Decide by	Cost if deferred
1	What is a tenant?	Day one	Rewrite every query
2	How does a request resolve to a tenant?	Day one	The most common real breach
3	Where does isolation live?	First paying customer	Audit everything you wrote
4	Roles, or permissions?	Customer three	Fix live roles retroactively
5	Which fields are secret, from whom?	Before your first aggregate endpoint	Find every reporting query
6	What happens when a workflow fails halfway?	Before money moves	Reconcile by hand
7	Per-tenant databases?	Wait	(this one is fine to defer)

(Disclosure: I work on Supero, which generates multi-tenant backends. I have written this so it is useful if you never touch our product; the decisions are the same on any stack. There is one linked section at the end about how we answer them, kept off this page on purpose.)

1. What is a tenant, exactly?

Not rhetorical. Get it wrong and every later decision inherits the error.

"Tenant" usually starts as a synonym for "customer," and then reality arrives: a customer with two departments that must not see each other; a customer who acquires another customer; a reseller managing fifteen accounts; a user who belongs to two tenants and switches.

With one flat tenant_id, the first case forces a fake second account, the third forces an application-level join that bypasses your isolation, and the fourth forces a session hack. All three are things teams actually do, and all three are how cross-tenant leaks ship.

Decide on day one. Pick a hierarchy even if you use one level of it for a year. organisation → workspace → user gives you room for departments and resellers without a migration. Adding a level later means rewriting every query you have.

2. How does a request resolve to a tenant?

The decision most checklists skip, and the one that produces the most real vulnerabilities.

Decision 3 asks where isolation is enforced. This asks where the tenant identity comes from. Subdomain? A signed JWT claim? A session lookup? Or — the one that ships breaches — an org_id in the request body that the caller supplies?

An isolation layer that cannot omit tenant scope is worth nothing if the scope it cannot omit was chosen by the attacker. Same for RLS keyed on a claim your API populates from user input.

Decide on day one, and write it down: the tenant identity comes from exactly one place, it is server-derived, and no request field can override it. Then grep for the places that do it differently, because there will be some.

3. Where does isolation live?

Three honest answers.

In the application. Every query carries WHERE tenant_id = ?. Fast to build, and it fails the moment one developer on one endpoint forgets. Not hypothetical: a statistical certainty as headcount grows. The failure is silent. 200, with too many rows.

In the database. Postgres row-level security, schema-per-tenant, or database-per-tenant. Much stronger, because forgetting is no longer possible: the database refuses. Costs are real: RLS is its own skill and can be subtly wrong; schema-per-tenant makes migrations an operational project; database-per-tenant makes cross-tenant analytics and connection pooling hard at a few hundred tenants. That last option is the physical tier of this same decision. See #7, and do not treat it as a separate choice.

In one shared producer below the application. Be clear-eyed that this is a disciplined version of the first option rather than a third tier: it is middleware. What it changes is that the scope is written once instead of at forty call sites, which removes the per-endpoint mistake, the single most common way isolation actually breaks. What it does not do is make the boundary unforgettable the way the database refusing a query does. Ask any vendor claiming this (us included) two things: does the producer have bypass branches, and what stops a new call site from skipping it entirely?

Decide by your first paying customer. Moving later means auditing every query you have ever written, and you will not find them all.

The test that tells you the truth: ask a developer to write an endpoint that leaks across tenants. If they can — if nothing stops them but their own care — that is your isolation model, and care does not scale.

Apply it to us, since it would be cheap to set a test we pass. We do not pass it cleanly. The shared producer removes the per-endpoint mistake. What it does not remove is three ways around the boundary that need no mistake at all: admin roles have documented exemptions, a user left in the platform's default-tenant gets project-wide read, and a request arriving with no session context returns allow. That last one is unreachable today, because authentication runs first, but it sits in the code. The honest score is "a developer cannot leak by forgetting, and can leak by being provisioned wrong." Better than the first option on this list. Not the same as the second.

The part of that we can demonstrate rather than assert is the narrow part. Re-inline the tenant scope at a call site and the gate that parses our own source fails, exit 1; leave the code alone and all 25 gates pass. That answers "can a developer write the leaking endpoint" and nothing else on the list, which is roughly the shape of evidence to demand from anyone answering this question.

4. Roles, or permissions?

Everyone starts with roles: admin, member, viewer. Everyone ends up needing permissions, because the fourth customer wants someone who can see invoices but not edit users.

The escape is a custom_roles table, and it is the right call. Two things go wrong:

Privilege escalation through role creation. If a tenant admin can create a role, they can create one with permissions they do not have, unless you enforce a ceiling: a created role can never exceed its creator's permissions and can never shadow a builtin. Five lines, missing from a surprising number of production systems.

Roles checked in the UI. If your frontend hides a button and your API does not check, you do not have roles. You have a suggestion.

Decide by customer three. Retrofitting a ceiling after tenant admins have created roles is worse, because you now have live roles violating the rule you are about to introduce.

5. Which fields are secret, and from whom?

Made last, regretted most, and where I have watched careful teams still ship a hole.

Hiding a field from a response is the easy half. A field nobody can see can still be used to compute. If a caller cannot see salary but can write ?order_by=-salary&limit=1, they read the highest-paid employee's name. ?distinct=diagnosis_code returns the value set, and for a low-entropy column the value set is the secret.

Response masking fixes none of it, because the leak is not in the body — it is in which rows came back and in what order.

The fix: the fields a caller may filter, sort, group and aggregate by must be the same set they may see, computed in one place. Two lists maintained separately will drift.

Decide before you build your first aggregate or reporting endpoint. That is where this bug is overwhelmingly introduced: aggregates get written later, by someone else, and take a raw field name.

Our own read-input guard for this is deployed and running in monitor mode, where it logs would deny read and returns the rows anyway. Which is to say the decision is easy to make and slow to finish, on any stack.

The full anatomy of that attack, and what a real fix requires.

6. What happens when a workflow fails halfway?

Your checkout reserves inventory, charges a card, creates an order. The charge succeeds. The insert fails.

Three levels of answer. Nothing: you find out from the customer, which is most early products, and mostly they get away with it. Retries and idempotency keys: necessary and insufficient, because retrying forward does not undo a half-applied sequence, and a non-idempotent money operation applied twice is worse. Compensation: step 4 fails, steps 3, 2 and 1 reverse. That is the saga pattern, and the actual answer.

Three things teams underestimate. Compensation logic is roughly the same volume as the forward path and is the code least likely to be tested, because writing a test that fails step four on purpose is annoying. The reversal can itself fail. Decide now what happens then, because "the reversal didn't reverse" needs an operator, an alert and a runbook. And a compensation engine is not the same as compensation coverage: every individual operation needs a correct inverse declared, and the ones that don't fail silently. Audit them one by one. Ours declares 119 states and 81 transitions across 21 service manifests, 19 forward operations carry a locked inverse, and we have still found mis-wired ones in there.

One precision worth having: for payments specifically, the clean pattern is authorize-then-capture, and you void an uncaptured authorization rather than compensating a completed charge. Compensation is for the steps around the money.

Decide before you take money. Not before you launch — before money moves.

7. Single database, or one per tenant?

The one everybody argues about first and should mostly argue about last. It is the physical half of decision 3, which is why it is here rather than earlier.

For most B2B SaaS, a shared database with strong isolation is correct until you have either a customer contractually demanding physical separation or a measured noisy-neighbour problem. Both are real and both arrive later than you fear. Premature database-per-tenant costs you migrations across N databases, connection pool exhaustion, cross-tenant analytics that were one query and are now a pipeline, and a provisioning flow you now operate.

Decide when a customer asks, or when you measure a problem. The one item where "later" is right.

What this multi-tenant SaaS checklist leaves out

Four more that bite, in rough order of how often I have seen them:

Per-tenant SSO and SCIM deprovisioning. Arrives with the first enterprise deal and retrofits badly.
Tenant deletion and data residency. "Delete Acme entirely from a shared database" is a legal obligation, and EU-resident tenancy is a day-one partitioning decision.
Per-tenant rate limits and quotas. Cheap now, brutal later — this article's own thesis.
Support impersonation. "View as Acme" is the standard isolation bypass, and it is usually unaudited.

Six of seven above are cheap today. That ratio is the point of the article, and it is why the seventh being deferrable matters: it is the one that looks like the big architectural decision and is not.

Frequently asked questions

What is the best multi-tenant architecture?

Shared database with isolation enforced below the application, until a customer contractually requires physical separation. The isolation layer matters far more than the physical layout.

When should I add multi-tenancy?

Before the second customer organisation logs in. Retrofitting isolation means auditing every query already written.

Is row-level security enough for multi-tenant SaaS?

It is a strong row boundary and the right default on Postgres. It does not cover which columns a caller may see or compute with, and it is opt-in per table.

How do I stop a tenant admin escalating their own permissions?

Enforce a ceiling on role creation: a created role cannot exceed its creator's permissions or shadow a builtin.

Do I need a database per tenant?

Almost certainly not yet. Wait for a contractual requirement or a measured problem.

What to do next

Run decision 2 against your own codebase this afternoon. Find every place the tenant identity is established and confirm none of them reads it from a request field the caller controls. That is a one-hour audit and it is the highest-value item on this list.

Then decision 5: pick a field some role cannot see, and try to sort by it. If the rows come back in the right order, you have found the next fortnight's work.

How Supero answers decisions 3 and 5 is the field-permission piece. What you can take with you if you ever leave is a separate page. Both are kept off this one so this one stays useful. Applied to specific tools: Bubble · Retool · Supabase · Lovable, Bolt and v0. Building these for clients: what to charge.

DEV Community: Supero

AI app builders and multi-tenant SaaS: the 30% you still write yourself

Why some code generates beautifully

The list of things that don't generate, and why it's always the same list

Credit where it's due: one of those six gets real attention

The CVE, stated precisely

Four tests, about an hour, useful regardless of what you build on

The three ways teams handle the 30%

How we split it, including the rows I'd rather not print

Where Lovable, Bolt and v0 beat us

When the 30% starts to matter

FAQ

Part 3, which is already published

What to do next

Supabase RLS is great. Here's the part you'll still build yourself.

1. RLS answers "which rows." Not "which columns, for whom."

2. Every policy is a policy someone has to remember to write

3. service_role bypasses all of it

4. Sub-tenancy gets awkward fast

The honest turn

Where Supabase simply wins

What to actually do next

What Supero doesn't do yet - the honest list!

The multi-tenant SaaS checklist: six decisions to make now, one to ignore

Overview

1. What is a tenant, exactly?

2. How does a request resolve to a tenant?

3. Where does isolation live?

4. Roles, or permissions?

5. Which fields are secret, and from whom?

6. What happens when a workflow fails halfway?

7. Single database, or one per tenant?

What this multi-tenant SaaS checklist leaves out

Frequently asked questions

What is the best multi-tenant architecture?

When should I add multi-tenancy?

Is row-level security enough for multi-tenant SaaS?

How do I stop a tenant admin escalating their own permissions?

Do I need a database per tenant?

Almost certainly not yet. Wait for a contractual requirement or a measured problem.

What to do next

3. `service_role` bypasses all of it