12.2 — App architecture options
On this page
12.2 — App architecture options
🚧 Admin preview — not yet generally available. Like the rest of the App Builder, this is part of the premium add-on that's currently dark-launched for VibeMap admins. The options below are the choices the builder reads when it compiles your app.
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 one 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 payments" and you get a checkout and an orders table instead. No prompt-roulette.
This page is the 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 simply 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're resolved 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 a few 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 that protects your authenticated pages.
| Choice | What you get |
|---|---|
| None | No sign-in pages. (The Supabase client and guards are still wired in, so other features that need a user keep working.) |
| Email & password | A 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 sign-in method you chose.
User roles
Choose how much role structure the app needs. This shapes the database's 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 | Everything above, plus an admins table and an admin override, so admins can 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. For now 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 to read, author/admin to 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. You get an admin Team page to send and revoke invites, an invite-accept page, and an "invitation required" gate for anyone without one. |
| 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 silently pretending it's done.
Where to go next
- The build itself → 12.1 App Builder.
- Review the schema you're about to build → 6.1 Generating schema.
- How it's compiled under the hood → Developer docs: 9.2 Architecture configuration.