DEV Community: Srikanth Reddy Kasa

Wholesale marketplace app Atelier asks for net terms before a card

Srikanth Reddy Kasa — Wed, 14 Oct 2026 14:30:28 +0000

Prepaid, Net 15, Net 30 or Net 60. This open-source wholesale marketplace app is the one reference app of the 19 with net payment terms.

The last decision a buyer makes at Atelier's checkout is when to pay. The options come from a single list near the top of schemas.py:

NET_TERMS = ["Prepaid", "Net 15", "Net 30", "Net 60"]

That list is the enum, the set of allowed values, behind payment_terms on the order and net_terms on the buyer's profile. We searched the other 18 apps for net terms and found none. Five others enable the same stripe_checkout service. None of them offers terms. Atelier's code is in the atelier folder.

One field, two routes through checkout

The checkout form has a terms dropdown, defaulting to Net 30. The submit button's label follows it: "Place order on Net 30" or "Pay with Stripe". placeOrder in ui/app.js creates the order as pending and unpaid, then writes its lines. After that the two routes part.

On net terms the order is updated to confirmed and stays unpaid. No card is asked for. The operator's dashboard counts unpaid orders under "On terms (unpaid)", and each order has a Mark paid button for when the money arrives.

On Prepaid the code on main calls services.stripe.checkout with the order total and redirects to the hosted checkout URL, and since the success URL carries Stripe's session id, the app can call retrieveCheckoutSession with it when the buyer comes back and write pay_state: 'paid' only if Stripe itself reports the session as paid or complete. A failed checkout call leaves the order unpaid, with a message asking the buyer to try again.

One more branch matters if you run a clone. When the Stripe service is absent from the environment, the code marks the order paid with payment_provider set to 'simulated', and the confirmation page says so in a banner.

An order that spans brands

The cart lives in the browser, in localStorage under one key. Each cart line remembers its brand_name, and the cart page groups lines under a heading per brand.

At checkout they become one order.

The order schema carries the counts a multi-brand order needs, next to the two fields that record how it was paid:

{"name": "item_count", "type": "integer"},
{"name": "brand_count", "type": "integer"},
{"name": "pay_state", "type": "string", "values": ["unpaid", "paid", "refunded"]},
{"name": "payment_provider", "type": "string"},

The lines are a separate object. OrderItem is declared with "parent_type": "order", so each line is a child of its order, and the front end reads them back with client.getScopedList('order', o.uuid, 'order_item'). Product is linked to its brand through a references block with a back-reference named products. It also keeps brand_name as a plain string, and a product card needs no second lookup. setup.py seeds enough to browse. We counted 13 brands and 59 products, one buyer profile on Net 30, and two orders. Order ATL-100412 is delivered and paid at $168.50. Order ATL-100488 is confirmed and unpaid at $256.00. Each spans three brands.

In this wholesale marketplace, brands are rows and buyers own their orders

Should each brand be a tenant, with its own separate data? A comment in config.py answers that for this app, and the answer is no. There is a single tenant for the marketplace operator. Brands are ordinary records inside it. The comment gives the reason: discovery across brands is the whole point of a marketplace.

So Brand and Product are the two public schemas and the storefront renders for a logged-out visitor. The buyer role, tenant_user, may read both. Its other three rules cover the buyer profile, the order and the order line, and each one carries the same filter, filter_field="owner_username" matched against $user.name, so a buyer's order list contains their own orders and no one else's while the operator (tenant_admin) sees every order on the marketplace. That is policy-based row scoping. The operator's rules are narrower than you might guess: delete is granted on brands and products, the two things the console has a delete button for, and on nothing else.

Confirmation mail and a buying assistant

In setup.py the order_confirmation workflow is bound to the event @create:atelier:order, so placing an order is what sends the email. The recipient is mapped from user.email, the signed-in buyer's account address. The address typed into the checkout form is stored on the order and is not where the mail goes.

In the operator's console, Mark shipped and Mark delivered are plain updates to order_state.

The storefront also has a curation panel. A buyer describes their shop, the code sends that description with the catalog to the ai service, and the reply is matched back to real product rows by name. When the service is unavailable the panel shows the bestsellers and says why.

All of it is 1,098 lines of React in ui/app.js, the one front-end file you edit.

Atelier is a demo of a wholesale ordering flow. The brands are seed data and nothing ships.

Place a Net 30 order, then clone it

One warning before you click. The demo scales to zero, so the first load can take ten to thirty seconds, and an idle one sometimes returns an error before it wakes. Try again if it does. The logins are shared and writable, so treat anything you create there as public.

The login page at atelier.supero.live lists a buyer and an operator account. Sign in as the buyer, add products from two brands, and check out on Net 30. Then sign in as the operator and find it in the console.

The source folder runs with:

git clone https://github.com/supero-platform/supero-apps
cd supero-apps/apps/marketplace/atelier
cp .env.example .env    # set SUPERO_DOMAIN and SUPERO_PASSWORD
./run.sh

There is no account to create first. The storefront is running in about two minutes on http://localhost:5661. Net-terms orders need nothing more, and the Prepaid route depends on the Stripe service. Replace the 13 brands in BRANDS with your own catalogue and open a project at supero.dev.

Disclosure: Supero is ours. Atelier is one of 19 reference apps we publish, and the platform it runs on is our hosted product.

We gave an AI assistant one paragraph and our backend. It built a working app in 16 minutes, on the second try

Srikanth Reddy Kasa — Tue, 13 Oct 2026 17:06:19 +0000

Last week we tried something we had been telling people was possible. We connected an AI coding assistant to our platform, gave it one paragraph describing a book club app, and stepped back.

This is what happened, including the parts that did not work.

The setup

Supero is a hosted backend for web apps. It provides the parts every app needs and few people enjoy writing: sign-in and access rules, with a database and an admin panel behind them. It also has an MCP server, which is how an assistant such as Claude Code or Cursor can talk to it directly.

The brief was one paragraph: members propose books and vote on next month's read, then RSVP to the monthly meeting. An organiser schedules the meetings. A member can change only their own vote.

We used Claude Code with a key that can build into one project and nothing else. Nothing was installed on the machine, and we wrote no code.

What the assistant did

It made 46 tool calls. It began by asking the platform who it was and which project it was allowed to build into, then read the build spec, which the platform serves live so that it always matches what the platform will accept that day. It turned the paragraph into a plan of records and screens, with a role for each kind of user. It fetched a reference app to copy patterns from. Then it wrote seven files and asked the platform to validate them. When they passed, it published a version and deployed it.

Validation and publishing both passed first time, in one to three seconds each. Nine minutes after the first call there was a URL.

Then we looked at the app

The deploy status said "running". The built-in test said "healthy". The home page said "No book selected for this month yet."

That was wrong. The starter data included a selected book. We asked the assistant to read the logs, and there it was: 8 of the app's 27 starter records had been refused by our own API, each with a permission error, while the records next to them went through. The setup step had printed a warning box saying the app was incomplete and should not be treated as a successful deploy. Then it exited normally, and every tool reported success.

A second deploy filled the gaps. Sixteen minutes after the first call we had an app we had clicked through, screen by screen: voting with a live tally, RSVPs that stuck, data that survived a reload.

We also found that the app's one automation never ran. The spec told the assistant to include a workflow. The deploy could not register it, said so in a log line, and carried on.

What we got wrong, plainly

Two faults, both ours, neither the assistant's.

First, a cache. When an app's access rules were written, one of our servers kept answering from the old rules for up to five minutes, so any request that happened to land there was refused while the request beside it, sent a moment later to a different server, went straight through. That is why the failures looked random.

Second, the workflow registration used the wrong identity inside the deployed app, one that is deliberately not allowed to touch service settings.

Under both sat a third problem, and it is the one worth remembering, because it is the reason two real faults could sit in plain sight behind a green status: every success signal we had checked that the app was up, and not one of them checked that what the app declared had actually been created.

What we fixed

Both faults were fixed within a day. We then wiped the test project and deployed the same app twice more. All 27 starter records were created both times. The workflow ran about five seconds after a member sent an RSVP. Deploys took about two and a half minutes.

Two things are still not right, and we are saying so. One of the checking tools still prints an out-of-date warning about workflows. And the status tool still reports only that the app started, so for now you should open the app and look.

What the assistant got right and wrong

Right: the access rules. A member can change their own vote and nobody else's. It stored each vote as its own record so the tally needs no extra lookups, which we had not asked for.

Wrong: voting never closes, though the brief implied rounds. A member cannot withdraw a vote, only change it. The first version greeted the user as "member" instead of by name.

None of that is hidden. The app is in a public repo with its source and a list of seven things it does not do yet.

Why we are publishing this

Because that list is the point. We have opened a repo for people who want to build this way. It has a step-by-step guide to a first app and 31 project briefs across 16 areas. It also has the book club app, with its known gaps listed and five of them open as issues. Within a day of opening them, someone we have never met claimed one.

You do not need to ask before building a brief, and several people can build the same one. The free plan covers three projects and asks for no card, though what it gives you is preview deployments that expire after thirty minutes. A URL that stays up is a paid plan. The apps you build are yours, under the MIT licence. The platform underneath is a hosted service, not open source. We would rather say that here than have you find out later.

Three things we would tell another team trying this:

Read the logs of your first real run yourself. Our dashboards were green the whole time.
Publish the gaps. A list of what does not work is an invitation; a polished demo is not.
Count one run as one run. Sixteen minutes is what happened to us once, after one redeploy. It is not a benchmark.

Repo: https://github.com/supero-platform/supero-mcp
First app, step by step: https://github.com/supero-platform/supero-mcp/blob/main/docs/first-app.md
The book club app and its gaps: https://github.com/supero-platform/supero-mcp/tree/main/apps/community/book-club

Did the post go out? Amplify, a social media management app, records it

Srikanth Reddy Kasa — Mon, 12 Oct 2026 11:41:37 +0000

This open-source social media management app enables eight services in config.py, four of them social networks, and keeps three fields on the post that stop the app from overstating what it did.

Press Publish on a post in Amplify and the app stores what happened next. The evidence is on the row. These are the last three attributes of Post in schemas.py:

# Real-posting result: did it actually post to the channel, or fall back to simulated?
{"name": "delivery", "type": "string", "values": ["live", "simulated", "failed"]},
{"name": "provider_post_id", "type": "string"},
{"name": "publish_error", "type": "string"},

We searched the config.py and ui/app.js of all 19 apps for the four posting services (instagram, linkedin, x_social, youtube). Only this app lists them. The hosted demo simulates posting, so a Publish there does not reach a real social network. The source is the amplify folder of the supero-apps repo.

A social media management app where four networks post and four are tracked

The platform enum has eight values. ui/app.js names four of them in a constant, REAL_CHANNELS, and a function called realPost maps each of those to an integration call. Instagram needs an image. YouTube needs a public video URL, held in the video_url attribute. For Facebook, TikTok, WhatsApp and Google Ads the function returns null, and the composer labels those channels "tracked only".

What happens next is the part to copy.

publish tries the real call first. If the provider answers with an id or a success status, the row is saved with delivery: "live" and that id in provider_post_id, and if the call throws, or comes back without a confirmation, or realPost has no call for that network, the row is saved with delivery: "simulated" and whatever error message there was goes into publish_error. The pop-up message differs too. A live post gets "Posted to LinkedIn for real". A simulated one is announced as simulated, with a prompt to connect the channel.

An operator and their customers in one tenant

Amplify models a SaaS business, so it has two audiences who never share a screen. The customer is a marketer. The operator is the company running Amplify. Both live in one tenant, a single shared set of records: a customer company is a row in Workspace, and setup.py scopes the marketer (tenant_user) to rows they own.

PolicyRule(entity="workspace", can_read=True,
           filter_field="owner_username", filter_match="$user.name"),

The same filter sits on the three working objects (channel, campaign, post) with create and update added. This is policy-based row scoping, and the workspace rule is read-only for the marketer. A customer can see their plan and billing state and cannot write to either.

The operator signs in as tenant_admin and gets a different console, with tabs for billing and for every workspace and campaign on the platform. Its MRR (monthly recurring revenue) tile sums mrr over workspaces whose state is active or past_due. We counted the seed: 4 plans and 6 workspaces, then 10 channels, 8 campaigns, 16 posts. On those rows the tile comes to $456 from four counted workspaces, and the marketer login owns 9 of the 16 posts.

Plan is the one public schema, so the pricing page renders for a logged-out visitor.

Why workflows comes last in the list

config.py enables eight services, and a comment above the list explains their order:

services: list = field(default_factory=lambda: ["email", "slack", "ai",
                                                "instagram", "linkedin", "x_social", "youtube",
                                                "workflows"])

The comment's reason is that event bindings are wired up when the workflows service registers, so every other service has to be present first.

There are three workflows and two of them have no button. campaign_launch is bound to @create:amplify:campaign and sends an email plus a message to the #campaigns Slack channel. workspace_welcome is bound to @create:amplify:workspace. The third, post_publish, is a saga that marks the post published, emails the owner and then writes the metrics, and its first step carries a compensate block that sets post_state back to scheduled if a later step fails.

Captions with a fallback you can see

The composer has an AI panel. You type a brief and pick platforms. It calls the ai service once per platform with a short style guide for each, asking for under 280 characters on X and for a hook line with a single call to action on LinkedIn, and when the service is unavailable or returns no text, generateCaption falls back to a template written for that platform.

Each draft card is tagged "AI" or "template", from a flag generateCaption returns with the text.

The front end is a single file, ui/app.js, 887 lines in the repo. You edit it and refresh the page.

Try the marketer, then the operator

One warning before you click. The demo scales to zero, so the first load can take twenty or thirty seconds, and an idle one sometimes returns an error before it wakes. Try again if it does. The logins below are shared and writable, so treat anything you create there as public.

Two demo accounts are listed on the login page at amplify.supero.live. Sign in as the marketer and open the Composer and Posts tabs. In the seed, two of the marketer's 9 posts are scheduled and two are drafts. Then sign in as the operator, whose console lists every workspace. The seed has six.

To run it from the source folder:

git clone https://github.com/supero-platform/supero-apps
cd supero-apps/apps/marketing/amplify
cp .env.example .env    # set SUPERO_DOMAIN and SUPERO_PASSWORD
./run.sh

It needs no account and is running in about two minutes on http://localhost:5672. Everything in the folder is MIT-licensed, while the platform underneath is hosted and its source is not open. Until a network's credentials are configured on your own domain, every publish will be recorded as simulated on the row. To build a scheduler around your own channels, the starting point is supero.dev.

Disclosure: Supero is ours. Amplify is one of 19 reference apps we publish, and the platform it runs on is our hosted product.

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.

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?

DEV Community: Srikanth Reddy Kasa

Wholesale marketplace app Atelier asks for net terms before a card

One field, two routes through checkout

An order that spans brands

In this wholesale marketplace, brands are rows and buyers own their orders

Confirmation mail and a buying assistant

Place a Net 30 order, then clone it

We gave an AI assistant one paragraph and our backend. It built a working app in 16 minutes, on the second try

Did the post go out? Amplify, a social media management app, records it

A social media management app where four networks post and four are tracked

An operator and their customers in one tenant

Why workflows comes last in the list

Captions with a fallback you can see

Try the marketer, then the operator

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

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

The app

Test 1: the field the client never receives

Test 2: the tenant boundary

Where the rules come from

The honest part

What this does not show

Try it

3. `service_role` bypasses all of it