Architecture options
On this page
Architecture options
The menu of choices the App Builder reads to compile your app — auth, roles, payments, content, teams, storage, and marketing pages. · Optional (premium)
When the App Builder turns your project into a running app, it doesn't guess the app's shape from your prompt. It reads a small set of architecture choices on your project and compiles each into real code — the same way every time. Pick "subscription payments" and you get a Stripe subscription flow, a billing portal, and a subscriptions table; pick "one-time" and you get a checkout and an orders table instead. No prompt-roulette.
This page is that menu: each choice and exactly what lands in the built app when you turn it on. Leave a choice at its default and the builder emits nothing for it — your app stays lean.
How it works
Your architecture choices live on the project (you set them when you create it, alongside the prompt). At build time they resolve into a single validated configuration that drives the compiler directly. Because the mapping is deterministic, the same choices always produce the same files — which is also why rebuilding after a spec change is predictable.
The choices fall into groups: authentication, user roles, payments, content, team & invitations, file storage, and marketing pages.
Authentication
Choose how people sign in. The builder emits a matching Supabase auth flow — sign-in/sign-up pages, the OAuth/confirm callback routes, session handling, and a route guard for your authenticated pages.
| Choice | What you get |
|---|---|
| None | No sign-in pages. (The Supabase client and guards are still wired in, so features that need a user keep working.) |
| Email & password | Classic email/password sign-in and sign-up. |
| Social | Sign in with Google / GitHub (OAuth). |
| Magic link | Passwordless email sign-in. |
Multi-factor (MFA) is a separate switch: turn it on and the app also gets a TOTP authenticator-app enrol and verify step on top of whichever method you chose.
User roles
Choose how much role structure the app needs. This shapes the row-level security (who can see and change what) and the server-side guards.
| Choice | What you get |
|---|---|
| Single user | Owner-only access — every row belongs to the user who created it. The simplest, safest default. |
| Admin + users | The above plus an admins table and an admin override, so admins manage all data. Admin-only pages are guarded with requireAdmin. |
| Role-based (RBAC) | A full roles / user_roles setup seeded with admin and member, role-checking helpers, and role-aware guards (requireRole, requireAdmin). |
Payments
If your app charges money, pick the model and the builder wires up Stripe end to end — including a signed webhook handler.
| Choice | What you get |
|---|---|
| Subscription | Recurring billing: Stripe Checkout, a customer billing portal, plan-gating, and a subscriptions table. |
| One-time | A one-off Checkout (payment mode) and an orders table. |
| Usage-based / Marketplace | Coming later. The build produces the closest working scaffold and flags the rest as not-yet-supported, so you can finish it by hand. |
Content
If your app publishes content, turn on the blog.
| Choice | What you get |
|---|---|
| Blog | A posts + categories schema (public read, author/admin write), public list and article pages, and an authenticated editor with create/edit/delete. |
| Full CMS | Coming later. You get the full blog scaffold today; media library and rich-text are flagged as not-yet-supported. |
Team & invitations
If your app is for a team, choose how people join. The builder adds a members registry and the matching join flow. (Today this models the whole app as one team; multi-workspace support comes later.)
| Choice | What you get |
|---|---|
| Open | Anyone who signs up becomes a member automatically, plus a read-only /team roster. |
| Invite-only | Members are added by invitation: an admin Team page to send/revoke invites, an invite-accept page, and an "invitation required" gate. |
| Approval | Anyone can request access; an admin approves. You get the request flow, a "pending approval" page, and an admin Team page to approve or decline. |
The access guard (
requireMembership) is generated for you, but you decide which pages to put it in front of — drop it into your protected layout to enforce the gate everywhere.
File storage
Turn this on and the app gets a private file area: a Supabase Storage bucket, a files table with owner-only access, an upload component, and a files page. Each user sees only their own files.
Marketing pages
Pick any of landing, pricing, about, contact, and help, and the builder adds those static pages. The pricing page is wired to whichever payments model you chose.
What's deferred
A few choices ship as a working starting point with the advanced parts flagged for you to finish: usage-based and marketplace payments, the full CMS (media/rich-text), and multi-workspace teams. The build always tells you what it left as a scaffold rather than pretending it's done.
↔ The traditional way
An architect normally makes each of these calls in a design doc, then a team hand-implements auth, RLS, roles, Stripe, and invitations — and every project re-litigates the same decisions and re-writes the same plumbing. Here the decisions are the configuration: each one compiles straight into consistent, known-good code, so two projects with the same choices get the same battle-tested wiring.
What's next
- Run the build → 14.1 App Builder.
- One-click plan-to-app → 14.3 Continuous build.
- Review the schema you're about to build → 7.1 Generating schema.