What Supero is, what it replaces, and what you still have to build

---

The rest of our engineering writing dives straight into a mechanism.

That is deliberate and it has a cost. People have been reading about our idempotency gate or our field permissions without ever being told what the product is, which is a strange way to introduce yourself.

So, plainly.

**Supero generates and runs the governed part of a B2B application.** The parts that every such application needs and nobody enjoys writing:

You either generate that from a description of what you want, or wrap it around a database you already have. The application code is yours, and it runs on our cloud or your own Kubernetes.

That is the category.

The rest of this page is what that means in practice, and where it falls short. There is a section for each, at roughly the same length. A page that spends nine paragraphs on capabilities and one on limitations has told you something about the vendor and nothing about the product.

A record here does not have a `tenant_id` column.

It has an **address**: `[domain, project, tenant, name]`. Your organisation. An application inside it. One customer of that application. Then the record itself.

Every read is scoped by matching a prefix of that address, and the prefix comes from the caller's token, never from anything the caller sends.

This is the difference that matters, and it is why several of our other articles keep referring to "the address".

In the `WHERE tenant_id = ?` model, isolation is a clause somebody has to remember to write. Every time. In every query, in every service, in every batch job somebody adds at 6pm on a Thursday because a report was due, forever, including the ones written by people who joined after whoever explained the convention had left. Forget it in one query out of four hundred and nothing fails. No error. No exception. Numbers that look plausible, and a cross-tenant leak that surfaces months later when a customer recognises a name they should not have seen.

In the address model, a record's tenancy is part of its identity rather than one of its fields, so a query that omits the scope is not a wider query. It is a query for records that do not exist.

Leaks are still possible. What moves is the shape of the mistake: from "somebody forgot a clause" to "somebody was provisioned into the wrong place". That is a much smaller surface and a much more auditable one. Say **logical isolation enforced at the query layer**. Physical isolation is what self-hosting gets you.

**A typed schema with a REST API over it.** Generated, with the object and field permissions attached and not bolted on afterwards.

**Roles at object and field level.** Ten roles exist and you assign eight of them. A field a role cannot read is stripped from responses.

The same hidden set is checked against filters and sorts too. A field you can sort by is a field you can reconstruct, one comparison at a time.

**22 transactional services with 117 operations.** Payment, with all four of authorize, capture, refund and void. Two-phase inventory reserve and commit. Booking, appointment, rental, subscriptions, membership. Loyalty points. Multi-signer document signature. Multi-step approval. Ticketing. A workflow engine that runs sagas across all of them.

This is the part nobody expects, and it is where most of the saved time actually lives.

**Connectors to a database you already own.** PostgreSQL, MySQL, SQL Server, Oracle, MongoDB, and the warehouses: Snowflake, BigQuery, Databricks, ClickHouse, Redshift, Microsoft Fabric. Each table is set to one of three modes: `sync` copies it on a schedule, `live_read` queries it in place, and `live_readwrite` writes back to it.

**Python and JavaScript SDKs, plus an exportable OpenAPI 3.0 spec.** Two SDK builders exist. Not TypeScript. Not Go. The spec is generated in the console and downloaded, not served. That matters if you were planning to point a tool at a URL.

**Deployment.** A live preview, managed cloud, or your own Kubernetes cluster. Prompt to a running preview takes under 10 minutes, and anyone who tells you it takes 47 seconds is quoting a number from a single unmeasured run.

**An exit.** Two export paths ship and neither is behind a plan.

Download the application as a `.tar.gz`, or sync it to a GitHub or Bitbucket repository you own. The repository is created private, with secrets and gitignored files stripped.

The export is one-way: code leaves, it does not flow back. Attachments are not included in a record export.

This list exists because the previous section reads like a list of things you do not have to do, and four of them are still yours.

**Your actual product.** The domain logic that makes your application worth paying for cannot be generated from a paragraph, and it is the part you should want to write.

**Anything customer-facing that is not CRUD.** The generated admin panel is an admin panel. A polished customer-facing UI is yours. That is one reason the OpenAPI export exists — hand the spec to whichever frontend generator you prefer.

**Multi-tenancy, if you did not ask for it at the start.** `is_multi_tenant` is a generation-time flag and it defaults to off. Fifteen of the sixteen applications in our public showcase are single-tenant for exactly this reason. Turning it on afterwards is expensive. Decide before you generate.

**Proration, dunning schedules and the business rules around subscriptions.** Subscriptions, periods and deferred cancellation are handled. What happens when a payment fails three times is a policy decision, and so is what a mid-period plan change is worth. We deliberately do not make either for you.

We publish this elsewhere and it belongs here too.

There is **no pricing page** today.

If you want to know what this costs, you have to ask. That is a bad answer to a fair question, and it is the single thing on this list most likely to be fixed first.

The sixteen showcase applications run **development builds** rather than production bundles. They are demonstrations, and they are not the benchmark for what a production deployment should look like.

Generated applications take the SDK **by floor, not by pin**. A deploy picks up the newest SDK above a minimum. That is the mechanism behind fixing something once and having it fixed everywhere, and it is also the risk that sits behind it: your running application can change when we publish, and you cannot currently pin it.

We are **not SOC 2 or HIPAA certified** and there is no BAA. The controls are designed with those frameworks in mind. That is a different sentence and should be read as one.

No third-party penetration test has been published either.

One command, no account, no signup:

curl -s https://api.supero.dev/mcp/v1/info

That returns the tool descriptor for our MCP server, including a count of the build tools an agent can drive. Nothing about it requires trusting us.

Then, if you want to see applications rather than a descriptor, `supero.dev/apps` indexes sixteen running ones across sixteen different verticals, each at its own URL. They are real, they respond, and you can poke at them before you ever create an account.

If you are evaluating: read what you can export from six platforms first, because the exit question is the one worth resolving before the feature questions.

If you are an engineer and want to know whether the substance is real, the honest test is to read one of the mechanism pieces and judge the thinking: the permission that returned zero rows to everyone is the shortest, and it is about a bug of ours.

If you want to build something now, the MCP surface describes driving a whole build from your editor, and `docs.supero.dev` has the path that does not require an agent.

*(Disclosure: I work on Supero. This page is the one piece of our writing that is straightforwardly about the product, which is why the weaknesses are listed at the same size as the features rather than in a footnote.)*