From a paragraph to a deployed app

What this gets you

You write a paragraph describing an app. A few minutes later you have a data model, a role-based admin console, a customer-facing surface, seed data so it is not empty, a REST API and SDKs, and a live URL. No project scaffold, no migrations, no auth to wire.

That is the demo, and the demo is real. What the demo skips is that generation happens in reviewable steps, and two of those steps are where you decide whether the app is any good. This guide is mostly about those two.

Seven steps, and where you actually intervene

Generation is a background job that streams progress to your browser — closer to watching a build log than chatting. It is one-way, and it stops at points where you get to look before it continues. The wizard's own numbered steps are Backend · Server · Frontend · Generate · Package · Deploy, with the mode and requirements brief before them:

1. Describe your app — plain English: the things it tracks, how they relate, who uses it. You can start from an uploaded reference instead of typing, and its text becomes the starting description.
2. Review the brief ← gate one. Your short description is elaborated into a fuller requirements brief. Read it and edit it before anything is generated.
3. Backend — schema (entities, fields, relationships), access policies and seed data are generated. ← gate two lives here: review this before you move on.
4. Server — the services, workflows and event rules that run on your data. Integrations are chosen here, not bolted on afterwards.
5. Frontend — app name and emoji, colour theme, tone for the written copy, navigation style, and which roles see which tabs.
6. Generate — App Studio builds the web app on top of the backend you reviewed.
7. Package — review everything: the files, the seed login accounts, and the downloadable bundle.
8. Deploy — one click to a live URL.

What to put in the paragraph

The generator is good at shape and unreliable at the details you did not mention. Three things carry most of the quality:

A property-management back office for a firm managing 40 buildings.

Entities: Property, Unit, Renter, Lease, MaintenanceRequest, Payment.
Each Property has many Units. A Lease links one Unit to one Renter and
has a start date, end date and monthly rent. MaintenanceRequests belong
to a Unit and have a priority and a status. Payments belong to a Lease.

Two kinds of user: property managers, who administer everything; and
renters, who sign in and see only their own lease, their own requests
and their own payment history.

Read the schema before you accept it

This is the one step people skip and regret. Everything generated afterwards sits on top of it. What you are looking for, in order of how expensive it is to fix later:

What you get is plain, readable source — not a black box. A generated entity looks like this, and you can edit it by hand at any point:

Task = {
    "schema_type": "object",
    "name": "Task",
    "namespace": "myapp",
    "parent_type": "tenant",
    "fields": [
        {"name": "title", "type": "string", "required": True},
        {"name": "status", "type": "string",
         "values": ["todo", "in_progress", "done"], "default-value": "todo"},
        {"name": "due_date", "type": "datetime"},
        # the policy below filters on this — filter_field must be a real field
        {"name": "owner_username", "type": "string"},
    ],
}

Alongside it you get one policy per role. default_access="none" is fail-closed — a role gets nothing on an entity unless a rule grants it, which is the default you want:

from supero.app_setup import PolicyDef, PolicyRule

access_policies = [
    PolicyDef(role="tenant_admin", default_access="none", rules=[
        PolicyRule(entity="task", can_read=True, can_create=True,
                   can_update=True, can_delete=True),
    ]),
    PolicyDef(role="tenant_user", default_access="none", rules=[
        PolicyRule(entity="task", can_read=True, can_create=True,
                   filter_field="owner_username", filter_match="$user.name"),
    ]),
]

What is actually generated

Plus the parts you never asked for and would otherwise build: full CRUD REST endpoints for every entity, typed SDKs, multi-tenant isolation, role enforcement on every request, audit logging, and an in-app AI chat your end users can ask questions with.

Changing it

Two ways, and you can mix them freely:

• Describe the change — "add a due_date field to tasks", "let managers see every team's tasks". It regenerates using your current app as context rather than starting over.
• Edit the files — the schema, UI and setup files are plain source. Open them and change them by hand.

What this will not do for you

• It generates a first draft, not a finished product. Shape and CRUD are reliable; cardinality, seed realism and lifecycle fields are the things to check every time.
• Generated styling is a starting point. Nobody ships it unchanged on a customer-facing surface. Budget for restyling separately from the build.
• Web is the only target right now. Mobile generation is temporarily switched off in the product, so plan for a web app.
• It will not invent your business rules. "An order cannot ship before it is paid" is not in your paragraph unless you put it there — and even then, real lifecycle rules come from extending a transactional service, not from prose.
• Services are chosen, not inferred. Payments, email and SMS are picked on the Server step — Supero recommends a set from your description, but nothing is wired in silently.

Where to go from here

• Prefer your own editor to a dashboard? The same app, built over MCP.
• Already have a database? Build the app on the data you already have.
• Need it to take payments or send email? Adding payments, email and SMS.
• Ready to put it somewhere permanent? Deploying: Supero Cloud, your AWS, your GCP.