Cursor prompt to build a SaaS starter app
A SaaS skeleton has three load-bearing walls: auth, org-scoped roles, and billing webhooks that survive retries and reordering. Handing this prompt to Cursor scaffolds all three plus team management and an .env.example, and the closing instruction to exercise signup through test-mode checkout surfaces integration gaps immediately rather than at launch.
Last updated
Scaffold a SaaS starter in a new project using {{language}} and {{database}}. Set up authentication with email plus password and OAuth, organizations with role-based membership (owner, admin, member), and subscription billing via {{addon}} with a webhook handler that updates the local subscription record idempotently, verifying signatures and handling out-of-order events. Build three areas: a public marketing page, an authenticated app shell with settings and team management (invite by email, revoke, change role), and a minimal admin view of organizations. Enforce authorization at the data layer, not just the UI, so a member cannot hit an owner-only endpoint directly. Write a test that requests an owner-only endpoint with a member's session token and asserts it returns 403. Seed a demo org and user, document required environment variables in .env.example, then run the test suite and the app, exercise signup through checkout in test mode, and list the directory structure you created.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Scaffold a SaaS starter in a new project using TypeScript and PostgreSQL. Set up authentication with email plus password and OAuth, organizations with role-based membership (owner, admin, member), and subscription billing via input validation with a webhook handler that updates the local subscription record idempotently, verifying signatures and handling out-of-order events. Build three areas: a public marketing page, an authenticated app shell with settings and team management (invite by email, revoke, change role), and a minimal admin view of organizations. Enforce authorization at the data layer, not just the UI, so a member cannot hit an owner-only endpoint directly. Write a test that requests an owner-only endpoint with a member's session token and asserts it returns 403. Seed a demo org and user, document required environment variables in .env.example, then run the test suite and the app, exercise signup through checkout in test mode, and list the directory structure you created.
Same task in other tools
Questions about this prompt
This is a big scaffold. Should it be one Cursor run?
In a fresh project it works as one agent run, but you get better results asking for the plan first, approving the structure, then letting it build. In an existing repo, split it: auth first, then orgs and roles, then billing, verifying each stage before starting the next.
How does the webhook handler stay correct when the billing provider retries or reorders events?
The prompt requires idempotent processing and signature checks: store each event id, skip duplicates, and apply state transitions based on the subscription's current status rather than assuming delivery order. Verify it by replaying the same event twice and confirming the record only changes once.
Why enforce roles at the data layer when the UI already hides admin buttons?
Hidden buttons do not stop a curl request carrying a member's token from hitting an owner endpoint. Data-layer checks mean every query filters by organization and role, so the API stays safe even when someone bypasses the UI entirely. That is why the prompt has the agent write a test sending a member's session token to an owner-only endpoint and asserting a 403 comes back.