DEV Community: Srikanth Reddy Kasa

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.

Here's my app's access control, the passwords, and a curl command. Go break it

Srikanth Reddy Kasa — Sun, 06 Sep 2026 20:39:37 +0000

I moved my app's authorization below the application code. Here is the live demo, the passwords, and the curl commands to try to break it.

Every B2B app I built before this one put authorization in the application code. A decorator here, an if user.role == 'admin' there, a query that remembers to add WHERE tenant_id = ?. It works, right up until one endpoint forgets, and then it is a data leak with a CVE number.

The thing that bothers me is that this is re-litigated in every codebase. The rule "policyholders must never see the fraud score" is a business fact. It ends up encoded across a serializer, three endpoints and a React component, and nothing structurally prevents the fourth endpoint from getting it wrong.

So I built the other version: the rules are a declaration, and the server applies them in front of the database, before application code runs.

That is an easy claim to make and a cheap one to fake. So here is a live app, the passwords, and the commands to check.

The app

Sentinel is an insurance claims system — policies, claims intake, adjuster review with fraud scoring, documents, and separate portals for policyholders and staff.

It runs two insurers on one deployment: Northwind Mutual and Cascade Assurance. Four logins, all with the password Password123!:

Tenant	Role	Email
Northwind Mutual	Policyholder	`member@sentinel.insure`
Northwind Mutual	Claims team	`claims@sentinel.insure`
Cascade Assurance	Policyholder	`member@cascade.insure`
Cascade Assurance	Claims team	`claims@cascade.insure`

The data is fictional and gets reset. Please don't put anything real in it.

There are two separate things to try to break: fields (can a policyholder get the fraud score?) and tenants (can Northwind get Cascade's book of business?).

Test 1: the field the client never receives

Adjusters see fraud_score and internal_notes on every claim. Policyholders must never see either. Log in as the policyholder and read the claims:

API=https://api.supero.dev

login() {
  curl -sS "$API/api/v1/auth/login" -H 'Content-Type: application/json' \
    -d "{\"domain_name\":\"supero-apps\",\"project\":\"sentinel\",
         \"email\":\"$1\",\"password\":\"Password123!\"}"
}

TOKEN=$(login member@sentinel.insure | jq -r .auth.access_token)

curl -sS "$API/api/v1/crud/supero-apps/sentinel:claim" \
  -H "Authorization: Bearer $TOKEN" \
| jq '{claims: .result_count,
       fraud_score:    [.results[] | has("fraud_score")]    | any,
       internal_notes: [.results[] | has("internal_notes")] | any}'

{ "claims": 9, "fraud_score": false, "internal_notes": false }

Now change one word — member to claims — and run it again:

{ "claims": 9, "fraud_score": true, "internal_notes": true }

Same endpoint, same query, no filter parameter. The fields are not in the JSON for the policyholder. Not display: none, not dropped by the frontend — never sent. Open devtools on the live demo and they are not in the network tab either.

Test 2: the tenant boundary

Both claims-team accounts are tenant_admin — the most privileged role in the app. Read claims as each of them:

for EMAIL in claims@sentinel.insure claims@cascade.insure; do
  TOKEN=$(login "$EMAIL" | jq -r .auth.access_token)
  echo -n "$EMAIL -> "
  curl -sS "$API/api/v1/crud/supero-apps/sentinel:claim" \
    -H "Authorization: Bearer $TOKEN" \
  | jq -c '[.results[].claim_number] | sort | .[0:3]'
done

claims@sentinel.insure -> ["CLM-202047","CLM-203980","CLM-204120"]
claims@cascade.insure  -> ["CLM-CA-88214","CLM-CA-88301","CLM-CA-88355"]

Northwind numbers its claims CLM-…, Cascade uses CLM-CA-… — deliberately, so a leak would be obvious on sight rather than needing a UUID comparison. Neither admin can reach the other's rows. There is no tenant_id in the request for anyone to tamper with; the tenant is bound to the session at login.

Where the rules come from

The login response includes the policy the server issued for that session. The client does not choose it, and cannot alter it — it is shown to the client so the UI knows what to render:

login member@sentinel.insure | jq '.policy.entities["sentinel:claim"]'

{
  "entity": "sentinel:claim",
  "can_create": true,
  "can_read": true,
  "can_update": true,
  "can_delete": false,
  "filter_field": "owner_username",     // row scope
  "filter_match": "$user.name",
  "hidden_fields": ["fraud_score", "internal_notes"],   // field scope
  "readonly_fields": ["status", "state", "created_by", "tenant_uuid", ...]
}

default_access for this role is none; every entity the role can touch is listed explicitly. The claims-team policy is the same document without the filter_field and hidden_fields lines.

The part I find genuinely useful: look at the schema that defines a claim and note what is not there. fraud_score is an ordinary integer attribute. Nothing in the data model marks it as secret. The sensitivity is declared separately, in the access policy, and applied by the server. Which means the answer to "who can see the fraud score?" is one file, not a grep across the codebase.

The honest part

If you go read the app's own source, you will find role checks in it:

c.isAdmin ? h('button', { onClick: … }, '🛡 Claims console') : null,

I am not going to pretend those don't exist, because you would find them in a minute and then disbelieve the rest. They decide what the UI draws. They are not what protects the data, and that is the whole point: if I deleted every one of them and shipped the claims console to policyholders, the console would render with the fraud score column empty, because the server still won't send the field. The UI check is a convenience. The enforcement is underneath it.

That is the difference I was after. In the version I have written five times before, that isAdmin check was the security boundary.

What this does not show

Being straight about the edges, because you'd find them anyway:

No field-level encryption here. The platform supports encrypted fields; this app doesn't use them, so don't read the above as evidence about encryption at rest.
The demo logins are shared and public, and they can write. The data is fictional and reset periodically.
This is one app's configuration, not an audit. I have shown you the two axes I claimed. I have not shown you that every endpoint in the platform is correct, and you should not take a blog post as proof of that.
The UI code is hand-written. The schemas, the API, the access enforcement and the admin console are generated from declarations; the custom screens in this app are a file I wrote by hand. I have seen "N bytes in, M bytes out" claims made about codebases like this one and I'm not going to make one.

Try it

The live demo is at sentinel.supero.live — sign in as a policyholder and as the claims team on the same claim and watch the payload change.

If you'd rather read the schemas and the access policy than run curl, the app is on GitHub under MIT: github.com/supero-platform/supero-apps (apps/insurance/sentinel).

Want this on your own data? The repo quickstart clones any of the 19 apps onto a domain you own in about five minutes, no card needed: docs/quickstart.md. Or start from scratch: app.supero.dev/register.

I'm curious where people land on this. The objection I expect — and half agree with — is that moving authorization into a declarative layer trades one failure mode for another: you can't grep for it, and a misconfigured policy is as bad as a missing if. If you've run something like this in production, I'd like to hear which way that went.

If you enforce authorization below the app layer, what broke first — and if you don't, what's stopped you?