Documentation/Start Here/Solutions Overview

Solutions Overview

Ten reference architectures you can build on Supero, plus two worked case studies. Each one names the object types involved, the platform services it leans on, and the page that takes you further.

A storefront architecture assembled from platform base types — Every solution below follows this shape: your object types extend platform base types, and the services and surfaces follow from that.

How to Read These

A solution is not a template you install. It is a shape — a set of object types, the platform services they extend, and the surfaces that fall out of them. You can reach any of these shapes from any of the five entry points described in Ways to Build.

Each page below follows the same structure: what the solution is for, the object model, which platform services it uses, what you get without building it, what you still have to decide yourself, and where to go next.

ℹ️ The mechanism underneath all of them

A schema opts into a platform service by extending that service's base type — for example a schema that extends payment:base_payment becomes something the payment service can act on. This is the single idea that connects every architecture on this page.

⚠️ What these pages will not do

They will not promise behaviour the platform does not implement. Where a solution needs logic you must write — contention rules on a booking, a renewal loop for a subscription, a capacity check at checkout — the page says so explicitly rather than implying it comes for free.

Foundations

Three capabilities that show up across almost every application. Read these first if you are not sure which architecture you need — most real projects use at least two of them.

Foundation

Connect Your Database

Foundation

External Integrations

Payments, email, SMS, storage and calendars, with credentials held in the keystore rather than your code. Open

Foundation

Workflow Orchestration

A record changes, a workflow runs, and services fire in a defined order with a per-step log. Open

Application Architectures

Seven application shapes, each with at least one working example behind it. The table gives you the distinguishing entities so you can find yours quickly.

Solution	The entities that define it	Leans on
Online Storefront	product, cart, order, payment, feedback	cart, order, payment, product
Multi-Vendor Marketplace	seller and shopper split, per-seller catalog	cart, order, payment, inventory
Appointment & Service Booking	service, staff member, time_slot, appointment	service, appointment, notification
Membership & Recurring Billing	plan, subscription, billing_cycle, invoice	recurring_plan, membership, payment
Events & Ticketing	event, ticket_tier, attendee, ticket	ticket, order, payment
Warehouse-Backed Reporting	read-only types over Snowflake or Databricks	connectors, RBAC, field policy
Approvals & E-Signature	approval, approval_step, document, signature	approval, document_signature, task

💡 Mixing shapes is normal

A gym is a membership business with a booking calendar. A conference is a ticketing app with a storefront. Pick the closest architecture, then borrow the object types you need from the neighbouring one — they extend the same base types, so they compose.

Case Studies

Two longer walk-throughs that follow one application from an empty project to something running, rather than describing a shape in the abstract.

Case study 1

A Multi-Tenant Issue Tracker over MCP

Workspace, team, project, issue and cycle — authored from an AI editor, with each customer in their own tenant. Read it

Case study 2

A Subscription Business, End to End

Memberships, class bookings, payments, and automation that fires when a booking is created. Read it

What Is Not on This List

It is as useful to know where Supero is not the right tool. The following are deliberately absent because there is no working example behind them today, and documenting them would waste your time.

Not documented	Why
Analytics or BI dashboard as a product	Metric cards and charts are a feature of every architecture here, not a standalone application shape.
CRM or sales pipeline	The contact and activity entities that exist are read-only mirrors from connectors, with no pipeline behaviour.
CMS, blog or publishing	No working example. A content model is easy; the editing and publishing surface is not provided.
ERP, general ledger or accounting	Invoices exist as billing artifacts of other architectures. There is no ledger, no AP/AR, no double-entry.
A native mobile application	Generated applications target the web. Mobile is not a surface today.

If your project needs one of these as its centre of gravity, say so early — [email protected] is the fastest way to get a straight answer about fit.

Where to Go Next

Not sure how to start

Five entry points and what each is good at. Ways to Build

Want the vocabulary first

Domain, project, tenant, object type, namespace. Core Concepts

Ready to write the model

Fields, references, enums and extends. Schema Reference

Thinking about production

Supero Cloud, your own AWS or GCP, or on-premise. Deployment

← PreviousPlans & Billing Next →Ways to Build

On this page