Bolt prompt to build a SaaS starter app
This prompt hands Bolt the full outline of a SaaS starter: public marketing pages, Supabase-backed auth, a protected app shell, workspace-scoped data, and role checks, with Stripe deliberately left as a flagged stub. You end up with a browsable product skeleton whose tenancy rules live in one data-access module instead of being sprinkled everywhere.
Last updated
Build a SaaS starter app for a product that helps small teams manage {{resource}}. Stack: React with TypeScript, Supabase for auth and application data, Stripe stubbed behind a feature flag rather than integrated.
Pages:
- Public landing: hero, three feature sections, pricing table with Free, Pro, and Team tiers, and a footer
- Sign up and log in with email plus password, and a magic-link option
- Protected app shell: dashboard home, a {{resource}} section with create, edit, and delete, a team page with invite-by-email, and settings with profile and workspace tabs
- Billing page with the current plan and an upgrade button calling a clearly marked placeholder checkout
- A dedicated {{addon}} page in the protected shell with its own sidebar entry. Give it a real empty state explaining the feature before any data exists and gate its actions by role like the rest of the app; if it touches payments or billing, keep it behind the same flag as the Stripe stub. Done means the sidebar link, the route, and the empty state all render in a fresh workspace.
Data model: workspaces, users, and memberships with roles (owner, admin, member), plus {{resource}} records scoped to a workspace. Every query filters by workspace id, enforced in one data-access module rather than scattered through components.
Behaviors:
- Unauthenticated visitors hitting app routes get redirected to login, then back to their intended destination
- Only owners and admins see invite and billing actions
- Optimistic UI on {{resource}} create and delete, rolling back on failure
Empty and error states: a fresh workspace shows an onboarding checklist; failed logins distinguish a wrong password from an unconfirmed email.
Styling: marketing polish on the public pages, a denser utilitarian layout inside the app, one primary color shared by both.
Do not implement real payment processing. Seed one demo workspace with sample records so the app is browsable right after the first sign-up.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Build a SaaS starter app for a product that helps small teams manage users. Stack: React with TypeScript, Supabase for auth and application data, Stripe stubbed behind a feature flag rather than integrated. Pages: - Public landing: hero, three feature sections, pricing table with Free, Pro, and Team tiers, and a footer - Sign up and log in with email plus password, and a magic-link option - Protected app shell: dashboard home, a users section with create, edit, and delete, a team page with invite-by-email, and settings with profile and workspace tabs - Billing page with the current plan and an upgrade button calling a clearly marked placeholder checkout - A dedicated input validation page in the protected shell with its own sidebar entry. Give it a real empty state explaining the feature before any data exists and gate its actions by role like the rest of the app; if it touches payments or billing, keep it behind the same flag as the Stripe stub. Done means the sidebar link, the route, and the empty state all render in a fresh workspace. Data model: workspaces, users, and memberships with roles (owner, admin, member), plus users records scoped to a workspace. Every query filters by workspace id, enforced in one data-access module rather than scattered through components. Behaviors: - Unauthenticated visitors hitting app routes get redirected to login, then back to their intended destination - Only owners and admins see invite and billing actions - Optimistic UI on users create and delete, rolling back on failure Empty and error states: a fresh workspace shows an onboarding checklist; failed logins distinguish a wrong password from an unconfirmed email. Styling: marketing polish on the public pages, a denser utilitarian layout inside the app, one primary color shared by both. Do not implement real payment processing. Seed one demo workspace with sample records so the app is browsable right after the first sign-up.
Same task in other tools
Questions about this prompt
Does Bolt actually connect the auth backend, or fake it?
Link a real Supabase project from the workspace connect menu before you generate, or immediately after, so signup and login write to real tables. Left unconnected, Bolt often mocks the auth layer so it looks finished while storing nothing, which is worse than an honest TODO. Magic links also need the site redirect URL set in the Supabase dashboard before they will land back in the app.
Why keep Stripe as a stub instead of asking for the real integration?
Real checkout needs secret keys and a webhook endpoint, neither of which belongs in a scaffold session. The flagged placeholder keeps generation focused on structure; swap in a proper server-side integration once the app lives somewhere with an environment for secrets.
Generation stopped partway through the page list. How do I recover?
Large scaffolds sometimes finish with files missing. Do not repeat the whole spec, which can trigger a rewrite of pages that were already fine. Name the gaps instead: "the team and billing pages are missing, generate only those two."