Launch checklist for founders

Most launch problems are boring ones: a webhook still pointing at test mode, a sign-up form that fails on Safari, an error nobody was alerted to. This is the list I work through with founders before an app goes public, grouped by area so you can hand sections to different people.

There's a PDF version of this checklist too. Use the download form on this page and you'll get the same items with tick boxes, ready to print or share with your team.

Why it matters

You only launch once to most of your audience. People who hit a broken sign-up or a confusing empty screen on day one rarely come back to check whether you fixed it. A checklist doesn't make the product better, but it stops avoidable mistakes from wasting the attention you worked to get.

It matters more for apps built with AI tools. Lovable, Bolt, v0 and the rest are excellent at getting a prototype working. They're less reliable at the parts nobody sees in a demo: access rules, live payment configuration, error handling and mobile edge cases.

Product and QA

Accounts and security

The second-account test is the one that finds the most. Sign up as a new user and try to load another user's records by changing an ID in the URL or the API call. If anything comes back, stop and fix it before launch. My free health check flags the common versions of this in AI-built apps.

Payments

If you take payments with Stripe, its go-live checklist is worth reading in full. The points that catch founders out:

• Objects created in a sandbox, such as products, prices and coupons, aren't usable in live mode. Recreate them in live mode and update the IDs your code uses.
• Live webhook endpoints are registered separately from test ones, and must handle delayed, duplicate and out-of-order events.
• Error handling should treat a declined card (card_error) differently from a problem on your side (invalid_request_error), and show the user something sensible for each.
• Rotate your API keys before launch in case they were saved somewhere outside your codebase during development.

My guide to adding Stripe to an AI-built app covers the set-up in detail.

Data and privacy

For a UK company, the main items are the ICO data protection fee, a privacy notice written for your actual app, consent for non-essential cookies and marketing emails, and processor terms with your suppliers. I've covered each one, with links to the ICO guidance, in GDPR basics for UK founders.

SEO and sharing

You don't need an SEO strategy on day one, but you need the basics in place so search engines and link previews work.

Google's documentation says a single sitemap can hold up to 50,000 URLs or 50MB uncompressed, you can submit it in Search Console's Sitemaps report or with a Sitemap: line in robots.txt, and Google ignores the priority and changefreq values. In Next.js, both files can be generated from the app directory:

// app/robots.ts
import type { MetadataRoute } from "next";
 
export default function robots(): MetadataRoute.Robots {
  return {
    rules: { userAgent: "*", allow: "/", disallow: ["/app/", "/api/"] },
    sitemap: "https://yourapp.com/sitemap.xml",
  };
}

// app/sitemap.ts
import type { MetadataRoute } from "next";
 
export default function sitemap(): MetadataRoute.Sitemap {
  const base = "https://yourapp.com";
  return [
    { url: `${base}/`, lastModified: new Date("2026-11-09") },
    { url: `${base}/pricing`, lastModified: new Date("2026-11-09") },
  ];
}

Analytics and monitoring

Keep analytics small at launch. Three or four events you actually look at beat fifty you never open. My guide to setting up analytics for an MVP has the event list I start from.

Hosting and domains

The region point is easy to miss. Vercel Functions default to iad1 in Washington, D.C., and Vercel recommends running them in the same region as your database, or as close as possible. If your database is in London, a London function region (lhr1) removes a transatlantic round trip from every query.

If your app still lives on the AI tool's own hosting, read moving off Lovable and Bolt hosting before launch rather than after.

Launch day and the first week

For getting people in the door, my guide to getting your first 100 users covers the hand-recruiting that works better than any launch post.

Run a soft launch first

The cheapest way to find launch problems is a week with a small group of invited users before the public launch. Ten to twenty people is plenty. Pick people who match your target user, not friends who will be polite.

Give them one job: use the product for something real, and tell you where they got stuck. Watch your error tracking and analytics while they do. A soft launch tests the checklist itself, because the things you ticked off in theory either hold up with real accounts and real data or they don't.

It also gives you something to say on launch day. A line such as "tested by 15 local vendors before launch" is a stronger opening than "launching today", and the feedback often changes what you put on the home page.

Keep a simple log during that week: what broke, who reported it, and whether it's fixed. Anything still open on launch morning goes on the known issues list, so support can answer quickly instead of investigating from scratch.

Common misses

The items I see skipped most often:

• Stripe still in test mode somewhere. Usually the webhook secret or a price ID.
• No error alerts. The app breaks overnight and the first you hear is a polite email two days later.
• Analytics before consent. The tag sits in the root layout and fires on every page.
• The empty state. It looks fine with demo data and baffles a real new user.
• Accounts in the wrong name. The domain or hosting sits on a freelancer's or an agency's account.
• The ICO fee. Quick to sort, and easy to forget.

Next step

This checklist is the last step of a bigger journey. My prototype to product guide covers everything leading up to it, and the guide to launching an AI-built app goes deeper on the fixes AI tools tend to leave.

If you'd rather not tick these off yourself, my Launch package takes a prototype to production: payments, hosting, analytics and the fixes in between, priced from the MVP Build and agreed in writing. Book a call and bring your list.