Developers/SDK/GitHub Resources

GitHub Resources

The open sample applications: nineteen production-shaped apps across industry verticals, each with its schemas, setup, tests and editor rules — readable, clonable, and the fastest way to see how a real Supero app is put together.

The sample repository

Sample applications live in one public repository: github.com/supero-platform/supero-apps. It holds nineteen applications organised by industry, each a complete Supero app rather than a snippet — the data model, the setup that uploads it, configuration, tests, and a runner script.

ℹ️ Read them even if you never run them

These are the clearest available answer to "what does a real schema file look like?" A generated app and a hand-written one land in the same shape, so reading one of these tells you what the AI is producing on your behalf and what you would be editing afterwards.

Vertical	App	What it models
crm	summit	Accounts, leads, deals and activities with owner-scoped private records and lifecycle states
customer-support	concierge	A ticketing desk with agents, queues and resolution flow
field-service	fieldops	Dispatch and scheduling for technicians working jobs in the field
fintech	ledgerline	Ledger and transaction modelling
fitness	pulsefit	Memberships, classes and bookings
healthcare	brightsmile · lumen	Two clinical practice models, patient records and appointments
hospitality	tavola	Reservations and covers
insurance	sentinel	Policies, claims and adjusters
life-sciences	trialcore	Clinical trial sites, subjects and visits
marketing	amplify	Campaigns, audiences and attribution
marketplace	atelier	A two-sided marketplace: sellers, listings and orders
media	backlot	Titles, rights and scheduling
mobility	relay	Fleet, drivers and trips
real-estate	haven · lattice	Listings, viewings and offers; and property management with leases, rent and screening notes
healthcare (multi-tenant)	medora	A hospital network on one deployment: three hospitals, encounters, prescriptions and labs
life-sciences (multi-tenant)	helix	Multi-site clinical trials across three sites, with the treatment arm withheld from blinded investigators
fitness (multi-tenant)	pulse	A gym chain across three locations: classes, bookings, memberships and check-ins

What is in each app

Every app follows the same layout, which is also the layout your own app will have. Twenty-six files, and the four that matter most are the first four.

File	What it is
schemas.py	The data model — object types, attributes, enums, references and parent types. The file you will spend the most time in
setup.py	The bootstrap: uploads the schemas, seeds records, and configures access. The largest file in each app, and the one that shows how policy is applied in practice
config.py	Domain, project and tenant wiring, plus feature configuration
ui/	The customer-facing surface
tests/	Per-app tests — around ten per application
run.sh · run.bat	The runner. Creates a virtual environment, installs requirements, invokes the CLI
Dockerfile · docker-compose.yml	Containerised run, if you would rather not install anything locally
CUSTOMIZATION.md	What to change first when adapting the app to your own domain
.cursorrules · .windsurfrules · CLAUDE.md	Editor rules, so a coding agent working in the repo already knows the platform's conventions

💡 The editor-rules files are worth copying into your own project

Each app ships identical rules for Cursor, Windsurf and Claude. They encode the conventions an assistant otherwise gets wrong — that a record's identifier is uuid rather than id, that every create must be parented, and that list filtering is a POST. Copying one into your own repository is the cheapest way to stop an AI assistant generating code that returns 200 and the wrong data.

Running one

bash

git clone https://github.com/supero-platform/supero-apps.git
cd supero-apps/apps/crm/summit
cp .env.example .env      # add your credentials
./run.sh

The runner creates a virtual environment, installs the requirements and hands off to the Supero CLI. You need an account and a domain first — see Create Your Account — because the app uploads its schemas into a project you own.

⚠️ It writes into a real project

Setup uploads schemas and seeds records against whatever domain and project your credentials point at. Use a project you are willing to fill with sample data — a CRM's worth of accounts and deals is tedious to unpick from a workspace you were using for something else.

ℹ️ Reading the schema first costs nothing

If you only want to understand the model, open schemas.py on GitHub. It is a few hundred lines of plain Python data structures with no framework in the way, and it will tell you more about how Supero works than any amount of prose.

Using one as a starting point

1
Pick the closest shape, not the closest industry
A marketplace and a field-service app differ more in structure than a CRM and a support desk do. Choose by whether the model matches — two-sided, ticketed, scheduled, transactional — rather than by the label.
2
Read CUSTOMIZATION.md
Each app names the specific things to change first, which is faster than diffing the whole schema against your requirements.
3
Rename the namespace
Every schema declares a namespace. Change it before the first upload — it is part of every type's address, and renaming afterwards means the records you already created are addressed under the old one.
4
Edit schemas.py, then re-run setup
Schema changes take effect on upload; there is no build step. Adding a field is safe, and removing one that already holds data is refused rather than applied.
5
Close the defaults before anyone else sees it
Sample apps are built to work immediately, which means permissive access and seeded demo credentials. Going to Production is the checklist.

🚨 A sample app is not a hardened app

These exist to be readable and to run on the first attempt. They ship with the defaults that make that true: seeded accounts, permissive access policies, and demo sign-in affordances. Every one of those is wrong for a real deployment, and none of them announce themselves. Treat a sample as a starting point you harden, never as a template that is already safe.

Contributing an app

The repository carries CONTRIBUTING.md, a security policy, and issue and pull-request templates. If you have built something on Supero that reads well, a pull request adding it under the right vertical is welcome.

ℹ️ Tell us how you are connected

When you submit, say whether you are an independent developer, a paid contributor, or on the Supero team. We publish it alongside the app. Paid and sponsored contributions are welcome — unlabelled ones are the only kind we turn down, because a showcase is only evidence if the reader can tell what they are looking at.

Next steps

The model

Schema Reference

Fields, references, hierarchy and extends — everything schemas.py is made of. Read it

The shape

Anatomy of a Supero App

What each generated file does and which ones you are expected to edit. Read it

Build it yourself

Ways to Build

App Studio, MCP, schema-first, from your data, or over the API. Compare them

Machine-readable

OpenAPI Export & Developer Tools

Export a spec of your own schemas, and try the endpoints in the playground. Read it

← PreviousBuild an App with Your Own AI Agent Next →CLI (App Runner)

On this page