Documentation/Getting Started/What is Supero?
What is Supero?
Supero turns a plain-language description of your app into a deployed, full-stack product: a data model, a staff admin console, a customer-facing web experience, and the REST API and SDKs behind it.
Overview
Supero is an AI-powered app generation platform. You describe the product you want in natural language, and Supero generates a complete, working application: a data model, a role-based staff admin console, a customer-facing web experience, and the REST API and client SDKs that connect it all together. The generated app deploys to a live *.supero.live URL.
Under the app is a multi-tenant backend platform: every schema you define instantly gets full CRUD endpoints, request-time role and tenant enforcement, and a set of ready-made transactional services (cart, order, booking, payment, messaging, and more) that your app can extend instead of rebuilding from scratch.
If you have not signed up yet, start at Create Your Account — it takes a couple of minutes and gives you a domain, a project and a tenant to work in.
ℹ️ Two ways to build
Most people build with the AI app generator: describe the product, review the generated schema and UI, and deploy. If you only need the backend, you can also skip app generation and use Supero purely as a headless CRUD API and SDK layer for your own hand-built frontend. Those two are the ends of a spectrum — Ways to Build compares all five entry points (App Studio, MCP, the CLI, the SDKs, and the REST API) side by side.
Generate an App
Describe the product you want to build, and the AI turns that description into a working full-stack application:
- •A data model (schemas with typed fields, relationships, and access rules).
- •A staff/admin console for the roles that operate the app.
- •A customer-facing web experience — a storefront, booking flow, portal, or dashboard, depending on what you described.
- •The REST API and SDK wiring needed for all of the above to talk to your data.
⚠️ Generated applications target the web
A mobile surface is not part of the standard generated bundle. The local CLI carries a --mobile flag that runs an Expo app alongside the server, but every generated app bundle records its mobile surface as null, and the option is not offered in the console. Treat mobile as an unproven path rather than something you can plan a delivery around — if it matters to your project, ask before you commit: [email protected].
The generated app deploys to a live URL on *.supero.live. You can keep iterating in natural language — ask for new fields, new pages, or a different workflow — and redeploy.
💡 AI-generated, and inspectable
Everything the AI generates — schemas, UI schemas, access policies, workflows — is readable and editable rather than an opaque artifact, and you can change any of it. Where the files start out depends on how you build. Building over MCP from your own editor authors them directly on your machine (schemas.py, config.py, ui_schemas.py, ui/app.js, run.sh) so they are in your version control from the first minute. In hosted App Studio you edit through the platform, and you can take the source out at any point — download the app as a .tar.gz, or push it straight into a GitHub or Bitbucket repository you own. What none of these paths give you is a two-way sync: the source leaves, it does not flow back. See Continuity & Exit for what you can take with you and what you would have to replace, and Ways to Build to compare the paths.
Platform Capabilities
These are the building blocks the app generator (and your own code, if you build headless) draws on.
| Capability | Description |
|---|---|
| App Generation | Natural-language description in, a deployed full-stack web app out: schema, admin console, and customer surface. |
| Customer Surface | The generated public/consumer-facing side of an app — storefront, booking flow, marketplace, or portal — as opposed to the internal staff admin console. |
| Transactional Services | Pre-built, extensible service primitives (cart, order, booking, payment, messaging, and others) that your schemas can build on instead of implementing from scratch. |
| Connectors | Bring-your-own-database and external-source connectors that sync outside data into your Supero project on a schedule or on demand. |
| MCP | An MCP server your own AI coding agent can connect to in order to author, validate, publish, and deploy a Supero app bundle end to end. |
| AI Agent | An in-app AI chat assistant that can be embedded in a generated app to help end users navigate and act on their data. |
| REST API + SDKs | Every schema gets full CRUD endpoints automatically; a Python SDK (and JavaScript access) let your own code integrate directly. |
| Role-Based Access | Every request is scoped by the caller’s role and tenant, enforced by the platform — not left to application code. |
Using Supero Headless
If you already have a frontend, or you just need a managed multi-tenant backend, you can use Supero without app generation. Define your schemas, and Supero exposes a full CRUD REST API and a Python SDK immediately — no UI generation required.
bash
curl -X POST https://api.supero.dev/api/v1/crud/acme/product \
-H "X-API-Key: ak_..." \
-H "Content-Type: application/json" \
-d '{"name": "Wireless Mouse", "price": 29.99}'python
import supero
org = supero.login(domain_name="acme", email="[email protected]", password="...")
product = org.crud.create("product", name="Wireless Mouse", price=29.99)
products = org.crud.list("product")Install the Python SDK with pip install supero. Requests can authenticate with either a JWT bearer token from login, or an API key sent as the X-API-Key header — never send an API key as a bearer token. See Authentication for how each credential is scoped.
How the Backend Is Organized
Whether an app is generated or hand-built, it sits on the same organizational hierarchy. Projects & Tenants walks through each layer in practice.
| Layer | Purpose |
|---|---|
| Domain | The top-level account. Contains one or more projects. |
| Project | An app’s isolated schema, data, and configuration. |
| Tenant | A data partition within a project, for serving multiple customers from one app. |
| UserAccount / ApiKey | The identity a request authenticates as; carries the role and scope that gate every request. |
Namespace is a separate, orthogonal label used to group schemas within a project — it is not another level of the hierarchy.
Roles are a fixed set: platform_admin and platform_user are Supero-operator roles, while domain_admin, domain_user, project_admin, project_user, developer, tenant_admin, tenant_user, and viewer are the roles you assign within your own domain, projects, and tenants. The Roles & Permissions Reference lists what each one can do.
Schemas Drive Everything
A schema defines one data type: its fields (name, type, whether it is required, allowed values, default value), its references to other schemas, and an optional parent_type for hierarchy. Every record carries system fields — uuid, created_at, updated_at, fq_name, parent_type, parent_uuid — and is always addressed by uuid, never id. The Schema Reference is the full field-and-reference model.
Schemas can extend a transactional service using extends: "<service>:<base>" — for example product:base_product for a sellable good, or service:base_service for a bookable offering — so your app inherits proven cart/checkout/booking behavior instead of reimplementing it. Transactional Services lists every base type available.
Because the REST API, admin console, and customer surface are all driven by the schema, changing a schema and redeploying keeps every generated surface in sync. Dynamic UI covers how the generated surfaces are described.
Deployment Options
A Supero app can be deployed to three kinds of targets — Choosing a Deployment Option compares them.
- •Supero Cloud — one-click hosted deployment at a *.supero.live URL, no cloud account required.
- •Your own AWS or GCP account — deploy the same app into infrastructure you control.
- •On-premise — install the signed supero-core package on your own servers with the supero CLI, using an offline signed license with no phone-home requirement.
Pricing is structure-based: a usage currency covers compute and AI generation, storage is billed separately, and plans include a monthly allowance plus optional prepaid credit packs and add-ons. Plans & Billing explains how the model works; current prices and plan tiers are on the Billing screen in your dashboard at app.supero.dev/billing.
Next Steps
Now that you know what Supero is, here is where to go next.
- •Read Core Concepts to understand domains, projects, tenants, and schemas in depth.
- •Follow the Quick Start guide to generate and deploy your first app.
- •Compare the five entry points in Ways to Build and pick the one that fits how you work.
- •See the Transactional Services reference to learn what your schemas can extend.
- •See the Connectors Overview to bring in data from your own database or an external source.
- •Supero is open-core. What you walk away with sets out exactly what you keep if you stop using it, and a playbook for freelancers and agencies covers the shape of that for client work.
On this page