Guide · Pre-launch
What to verify before launching a Next.js SaaS starter
Most launch failures are not exotic. They are an unsigned webhook, an email that never sends, or a build that passes locally but breaks a route in production. Verify the boring path first, because that is the part a buyer actually pays for.
Quick answer
Before launching a Next.js SaaS starter, verify the full commercial path end to end: Stripe Checkout completes, the signed webhook persists a purchase, the transactional email actually arrives, Postgres records are written, public discovery files (robots, sitemap, llms.txt) resolve, and npm run build passes with no route or metadata errors.
Prove the money path before anything else
A SaaS starter only earns trust once a real payment turns into a real fulfilment. Run a test purchase end to end and confirm each link in the chain, rather than assuming Checkout success means the rest worked.
- Stripe Checkout completes and returns to your success page.
- The webhook signature is verified, not just received.
- A purchase record is written to Postgres with the right metadata.
- The buyer gets a delivery email and you get a sale alert.
Confirm email actually leaves the building
Transactional email is where silent failures hide. A misconfigured provider key or unverified domain can make sends look fine in code while nothing reaches the inbox. Test with a real address before launch.
- Send onboarding and download emails to a live inbox you control.
- Check the sending domain is verified with your provider.
- Confirm support and seller-notification paths fire as expected.
Check discovery and indexing surfaces
If you want search engines and AI answer engines to find the product, the discovery files have to resolve in production, not just locally. These are cheap to verify and easy to forget.
- robots.txt allows the right crawlers and points to the sitemap.
- sitemap.xml lists every indexable page with current dates.
- llms.txt and any service manifest describe the product honestly.
- Structured data validates on your key commercial pages.
Run the production build and a final setup check
A green local dev server is not proof. The production build is where missing metadata, broken routes, and type errors surface. Pair it with a setup check so you do not sell against a half-configured environment.
- npm run build passes with no route or metadata errors.
- Tests and lint are green.
- A setup check confirms Stripe, Resend, and Postgres are connected.
FAQ
Common questions
What is the single most important thing to verify before launch?
That a real test purchase flows all the way through: Checkout, signed webhook, Postgres record, and delivery email. If that chain holds, you have a sellable product; if it does not, nothing else matters yet.
Why verify discovery files like llms.txt and sitemap.xml?
Because search engines and AI answer engines rely on them to understand and cite your pages. If they only work locally, your production site is invisible to the systems that drive discovery.
Is a passing dev server enough to launch?
No. Run the production build, because it surfaces missing metadata, broken routes, and type errors that a development server tolerates.