Build a SaaS App

Define the first workflow and create a reproducible project

Keep the first subscription product narrow. Establish the expected behaviour before selecting packages.

1. Write one user story, the records it creates, the paid entitlement and the expected failure behaviour.
2. Create a Next.js project using the official installation guide. Record the chosen version and commit its lockfile.
3. Separate local, preview and production configuration. Use sandbox accounts while building.
4. Acceptance: a clean checkout installs, builds and starts using the documented commands.

Design account isolation before connecting real data

Authentication identifies a person; database permissions determine which records that person may access.

1. Draw the tables and ownership boundaries. Decide whether a record belongs to a user or an organisation.
2. Follow Supabase’s current Next.js SSR guide for browser/server clients and session refresh. Its implementation depends on the Next.js version.
3. Enable and write row-level security policies for each exposed table. Keep privileged keys on the server.
4. Implement sign-up, sign-in, sign-out and account recovery using current official examples; verify identity server-side before protected reads and writes.
5. Acceptance: two test accounts cannot read or modify each other’s records, even by calling the API directly. Test signed-out and expired-session paths.

Create checkout from trusted server state

Your server chooses the customer, account and allowed plan; the browser requests an action rather than declaring payment entitlements.

1. Follow Stripe’s subscription Checkout guide in a sandbox. Keep allowed price IDs in server-owned configuration.
2. Verify the signed-in user on the server and map that user to your own account and Stripe customer record. Do not trust a posted user ID or arbitrary price ID.
3. Create the Checkout Session server-side and associate it with the verified account. Use approved return URLs.
4. Acceptance: a signed-out request is rejected, an invalid plan is rejected, and one user cannot create billing for another account.

Handle billing events, retries and cancellation

Payment events update your stored entitlement. They must be authenticated, recoverable and safe to repeat.

1. Use Stripe’s webhook documentation to verify the signature against the raw request body.
2. Store event IDs and process updates idempotently. Associate events with the server-owned account/customer mapping.
3. Define access for trial, active, failed-payment, cancelled and refunded states; keep those rules in one server-side decision path.
4. Provide an account billing-management route and reconcile missed events from the provider when required.
5. Acceptance: an invalid signature is rejected; a replay does not duplicate writes; successful checkout grants the correct entitlement; cancellation and failed payment follow the stated policy.

Add transactional email with a recoverable delivery path

Keep account and billing messages separate from optional marketing subscriptions.

1. Follow Resend’s quickstart and domain-verification guidance. Use server-side credentials.
2. Send from verified identity, escape user-supplied values and avoid secrets in emails and logs.
3. Handle provider rejection, retries and duplicate triggers. Show confirmed acceptance accurately; it does not guarantee arrival in an inbox.
4. Acceptance: a sandbox message reaches the intended test recipient, provider failure is visible, and replaying an event does not send the same message repeatedly.

Validate the deployment before opening the product

A production URL is the start of an operational system, not the end of the work.

1. Use the Next.js production checklist and the hosting provider’s deployment documentation.
2. Configure production secrets, approved auth redirects, verified email identity and the live webhook endpoint separately from sandbox configuration.
3. Test the complete account, payment, cancellation, recovery and failed-request journeys on a preview first.
4. Record backup and restore steps, a rollback version, logging and alert ownership, rate limits and cost limits.
5. Check keyboard/mobile use, privacy information, applicable customer terms and support contact.
6. Acceptance: the checks above pass from a fresh browser; restore and rollback have been rehearsed; a named owner can respond to a failed billing or auth event.