SaaS Launch Checklist: 47 Things to Do Before Launch

Why most launches go sideways

Founders don't fail at launch because the product is bad. They fail because they ship at 9 AM and at 9:07 AM someone hits an edge case that crashes the signup flow, and by 9:15 AM the Product Hunt thread is full of people saying "doesn't work for me". Then the launch is over.

The fixable mistakes are almost always logistical, not strategic. Forgot to test the password reset email. Forgot to add a privacy policy. Forgot to set up billing in the production Stripe account. Forgot to plug analytics in. Forgot to write the onboarding copy. Forgot to test on mobile Safari.

This checklist is what founders who've launched multiple SaaS products run through in the two weeks before going live. It's not glamorous. It's the bare minimum to avoid embarrassing yourself in front of the audience you've spent months trying to earn.

Print it out. Cross things off. Don't launch until at least 42 of 47 are done.

Product readiness (1 to 12)

1. Run a fresh signup from an incognito window on a device that's never visited your site. Time it. If it takes more than 90 seconds from landing page to "I'm in the app and I see something useful", fix the flow before anything else.

2. Test signup with Google OAuth, email/password, and (if you have it) magic link. Each path breaks differently. Each one needs to work.

3. Test the password reset email actually arrives. Half of pre-launch SaaS apps have a broken reset flow because the founder used a hosted Supabase or Clerk template and never sent a real reset.

4. Test signing up with a typo'd email. Does your app handle bounces? Does the user know they need to verify?

5. Confirm email deliverability. Send a signup confirmation to a Gmail, an Outlook, a Yahoo, an iCloud, and a custom domain. Check spam folders. Set up SPF, DKIM, and DMARC on your sending domain.

6. Sign up, log out, log back in. Twice. Session bugs only show up after a real round-trip.

7. Try to break your forms. Submit empty forms, paste a 10,000-character string into a field, upload a 200MB file to your image uploader. Either handle it gracefully or block it cleanly.

8. Test the unhappy paths. Card declines, expired sessions, network drops in the middle of an upload, what happens when someone tries to access another user's data by changing the URL.

9. Verify mobile works. Open every key flow on a real iPhone Safari and a real Android Chrome. Not the Chrome dev tools simulator. A real device. Most pre-launch SaaS is built and tested entirely in desktop Chrome and breaks on mobile.

10. Verify dark mode works (or doesn't break the layout when the OS is set to dark). Half of launch-day visitors browse in dark mode.

11. Check page speed. Run your landing page and your most-important app page through PageSpeed Insights. Anything under 60 mobile score is going to bleed signups. Most issues come from unoptimized images and uncompressed JS bundles.

12. Set up basic error monitoring. Sentry or LogRocket. You will not catch bugs on launch day without it.

Pricing, billing, and accounts (13 to 19)

13. Set up a real Stripe production account. Not test mode. Real keys, real webhook signing secret, real product and price IDs.

14. Test a real $1 charge from a real card. Then refund it. Confirm the webhook fires, the subscription updates in your DB, and the user gets the welcome email.

15. Test the cancellation flow. Make sure users can downgrade and cancel from inside the app, not by emailing you.

16. Make pricing public. "Contact sales" pricing on a self-serve SaaS launch will cut your conversion by 50% or more. If you absolutely need a custom tier, show the other tiers and put "custom" as the highest one.

17. Write your refund policy. One short paragraph. Where it lives in the app. Who to email.

18. Set up a billing page where users can change card, download invoices, and update billing address. Stripe Customer Portal will do this in 10 minutes if you don't have one.

19. Decide your trial mechanics. Free trial with no card? Free trial with card? Freemium? Pick one, write it clearly on the pricing page, and don't bury the terms in fine print.

Legal and trust (20 to 25)

20. Publish a privacy policy. Not a generated one full of placeholder text. A real one that says what data you collect, why, and who you share it with.

21. Publish terms of service. Cover refunds, liability, acceptable use, account termination. A real lawyer for an hour costs less than the lawsuit.

22. Publish a cookie policy if you operate in or sell to the EU/UK. Add a cookie banner if you use any non-essential cookies.

23. Add a contact page with a real email address. Not a form. People want to know they can reach a human.

24. Add a footer with your legal entity name, country, and a "made by" line if you're a solo founder. Trust is built in the details.

25. Set up a status page. Even a single static page that says "all systems operational" is better than nothing. Status pages quietly increase enterprise trust.

Marketing assets (26 to 33)

26. Write your single-sentence pitch. "[Product] is the [category] for [audience] that [unique value]." Memorize it. Use it everywhere.

27. Record a 60 to 90 second product demo video. Loom is fine. No music, no fancy editing, just you walking through the product. This will be the most-viewed asset of your launch.

28. Build a hero image (or hero video) for your landing page that shows the product in action, not a generic illustration. Stock photos of laptops on desks are an instant signal that you don't know what you're doing.

29. Build at least 4 social-ready images. A square for Twitter, a 16:9 for LinkedIn, a vertical for Instagram or TikTok, a Product Hunt gallery image. Same brand, different crops.

30. Write three case studies or testimonials. Even from beta users. Even informal. "Saved me 4 hours a week, the onboarding was the cleanest I've used in years." Two sentences with a real name and a real headshot.

31. Build a launch landing page that's separate from your homepage if you're running multiple launches. /launch, /producthunt, whatever. Track conversion by source.

32. Set up OG images for every shareable URL. When someone shares your link on Twitter, Slack, or LinkedIn, the preview should look intentional.

33. Write your launch copy variants. Product Hunt tagline, Show HN title, Twitter launch tweet, LinkedIn launch post, email to your list. Each one is different. Each one needs to be written, not adapted.

Analytics and feedback (34 to 38)

34. Install web analytics. Plausible, Fathom, PostHog, or Google Analytics 4. Verify it fires on every page.

35. Install product analytics. PostHog or Mixpanel or Amplitude. Track at minimum: signup, activation event, key feature use, subscription started, churn.

36. Set up UTMs for every launch channel. /?utm_source=producthunt, /?utm_source=hackernews, etc. Otherwise you'll have no idea what worked.

37. Plug in a session replay tool for the first two weeks. PostHog has it free. Watch the first 100 sessions. It will be humbling and incredibly useful.

38. Add an in-app feedback widget. Frill, Canny, or a simple "what's missing?" form. Launch traffic gives you the most concentrated feedback you'll ever get.

SEO and discoverability (39 to 43)

39. Write a real meta title and meta description for every public page. Title under 60 characters, description under 158, both should include the keyword someone would actually search.

40. Add JSON-LD structured data for your homepage (Organization), pricing (Product), blog posts (Article), and product directory entries.

41. Build a sitemap.xml and submit it to Google Search Console the day before launch. Verify ownership of your domain.

42. Build a robots.txt that allows everything by default and references your sitemap.

43. Get listed in at least 5 directories before launch day. Code & Tell, BetaList, your category's niche directory, and 2 awesome lists on GitHub. Backlinks compound for years.

Support and ops (44 to 47)

44. Set up a real support inbox. support@yourproduct.com forwarding to your real email. Auto-reply with a 24-hour SLA.

45. Pre-write 10 canned responses for the most common questions you expect. Pricing, refund, "does it work with X?", "is there a free plan?", "how do I cancel?".

46. Set up a public roadmap or changelog. Productlane, Canny, or a simple markdown page. Launch-day visitors love seeing what's coming.

47. Schedule a 30-minute "all hands on deck" block for launch day at the time your biggest channel goes live. No meetings, no other work, just monitoring the launch and replying.

The day before

Read through the list one more time. Anything still red, decide right now: fix tonight or delay the launch a week. Don't rationalize a half-finished item into being okay.

Do a final dry-run of every payment flow with a real card. Send the launch email to yourself first. Open the landing page in three different browsers. Sign up as a new user one last time.

Sleep 8 hours. Seriously. Launch days are long and the people who try to push through on 4 hours of sleep make poor decisions when something inevitably breaks.

The week after

Most founders treat launch week like the goal line. It's the starting line. The first 48 hours show you which assumptions are right and which are completely wrong. Within a week you should have:

• Written down every common piece of feedback and grouped it by theme
• Decided which 3 things to ship in the next 30 days based on that feedback
• Followed up personally with every signup that engaged but didn't activate
• Asked your best new users for a written or video testimonial
• Posted a launch retrospective on Indie Hackers or your blog with real numbers

Conclusion

A SaaS launch is mostly a logistics exercise. The product is the part you already know. Everything else on this list is what separates a launch that lands from one that quietly dies on day one.

You don't need to do every item. You need to do most of them, and you need to do the critical ones (signup works, billing works, emails arrive, legal pages exist, demo video records cleanly) without exception. Skip the polish you can come back to. Don't skip the basics.

The 5 sub-checklists most founders forget

Payment edge cases

Test a card that succeeds, one that requires 3D Secure, one declined for insufficient funds, an expired card, and Visa, Mastercard, Amex, Apple Pay, Google Pay. Test what happens when a trial ends and the user has no card on file. Test mid-cycle downgrade and upgrade prorating. Test cancellation: can a user cancel without emailing you? If not, fix that before launch.

Email and notifications

Welcome email arrives within 60 seconds. Password reset within 30 seconds. Receipt after first payment. Trial-ending warnings at 3 days, 1 day, and 1 hour. Trial-ended email with next steps. All emails work in dark mode (test Gmail, Outlook, Apple Mail). Every email has an unsubscribe link. Sending domain has SPF, DKIM, and DMARC configured.

App-internal trust signals

Footer with support email on every page. Settings page shows plan, billing cycle, next charge date. Sensitive actions require confirmation. App version visible somewhere. A what is new or changelog link in the nav.

Onboarding the first 5 minutes

A new user sees something useful within 60 seconds, not an empty dashboard. An onboarding checklist exists. Sample data is available for users who do not want to set up their own yet. A skip onboarding option exists. Forcing onboarding loses 15 to 25 percent of signups at the first friction point. An in-app talk to founder option for users who want a person.

Post-launch monitoring

Sentry or PostHog session replay catching every error. Daily Slack alert with: new signups, trials started, paid conversions, churn, errors caught, top 5 support tickets. Stripe webhook events monitored. Uptime monitor on landing page and app domain. A pre-written incident response template.

What done actually looks like

Done does not mean perfect. Done means a stranger can land on your homepage, understand what you do in 5 seconds, sign up in under 60 seconds, do something useful within their first 5 minutes, and pay you within their first week without ever needing to email support. Everything else is polish. The founders who try to add more to this checklist before launch usually do not ship. The founders who ship with these 47 items handled (and the rest as backlog) get to feedback fast and iterate faster than anyone trying to be perfect.

at least three people you trust to look for embarrassing typos.

Your launch isn't everyone's launch

The 43 checks above are the table stakes to avoid a technically embarrassing launch. But they don't guarantee anyone shows up.

Getting people to show up isn't about carpet-bombing every channel. That's a great way to get zero traction everywhere. A successful launch is about surgically targeting the two or three places where your Ideal Customer Profile (ICP) actually hangs out.

A generic checklist is a trap. Your launch plan should look radically different if you're a solo devtool founder versus a vertical SaaS founder selling to dentists. One needs to nail a Show HN post. The other needs to be in a private Facebook group for dental practice managers. Doing both is a waste of time. Your most limited resource at launch isn't money. It's focus.

Don't boil the ocean. Pick your audience, find their watering holes, and build your launch exclusively for them.

ICP-specific launch checklists: What to do (and what to skip)

The real work isn't doing everything. It's doing the right four things and ignoring the other 40. Here's a cheat sheet for four common founder types. Find yourself, copy the plan, and ignore the rest.

The Solo Devtool Founder

Your ICP is a backend engineer who hates GUIs and lives in the terminal. They trust code, not marketing copy.

A solo devtool founder selling a $19/mo CLI for managing database migrations doesn't need a big Product Hunt launch. They need credibility with other developers. Your launch isn't a party, it's a pull request.

Your Checklist:

1. Polish your GitHub README. This is your real landing page. It needs a crisp one-sentence description, a GIF showing the tool in action (use terminalizer or asciinema), clear installation instructions, and a link to your real docs.
2. Publish to the package manager. Your tool has to be installable via npm, pip, gem, or brew before you tell anyone about it. The first thing a developer will do is try to install it. If they can't, you've lost them.
3. Write a "Show HN" post. The title must be: "Show HN: I built [Tool Name], a [One-sentence description]". In the first comment, add a plain-text, detailed explanation of why you built it, who it's for, and what problem it solves. Be prepared to spend the entire day in the comments answering technical questions.
4. Crosspost to dev.to and Lobste.rs. Take your Show HN comment, turn it into a short blog post, and post it to developer-centric communities. Use the same direct, technical tone.

What to Skip: A big Product Hunt launch, a LinkedIn personal branding blitz, paid ads, chasing testimonials. Developers don't care about any of that. They care if the tool works and if the creator knows what they're talking about.

The Vertical SaaS Founder (HR, Legal, Fitness)

Your ICP is a non-technical business owner who's too busy to learn new software. They don't read tech blogs. They trust other people in their industry.

A founder selling a $249/mo scheduling tool for boutique fitness studios wins by being "one of them," not by being a "tech founder." Your launch is about infiltrating a community, not broadcasting to the world.

Your Checklist:

1. Get one anchor testimonial. Before you launch, find one friendly customer in your niche. Give them the product for free for six months in exchange for a killer quote and their headshot. Put it front and center on your landing page. "This saved me 10 hours a week on class scheduling" from a real studio owner is worth more than 1,000 upvotes.
2. Become an active member of 2-3 industry groups. Find the private Facebook Groups, Slack channels, or forums where your ICP asks for advice. For a fitness SaaS, it might be "Fitness Business Owners of America." For a legal tech tool, it's a specific Bar Association listserv. Don't spam your link on day one. Spend a month answering questions and being helpful. Then, on launch day, post something like, "Hey everyone, a few of you know I've been working on a tool to solve [problem]. I just opened it up today for new signups."
3. Pitch one trade publication. Ignore TechCrunch. Find the niche online magazine or newsletter your ICP reads. For restaurants, that's Restaurant Dive. For HR, it's HR Brew. Send a personal email to a journalist there with a clear story: "[My SaaS] helps [restaurant owners] solve [specific problem] which costs them [$X per year]."

What to Skip: Hacker News, dev.to, Product Hunt. Your customer has never heard of these sites and would be confused if they landed there.

The B2B Horizontal SaaS Founder

Your ICP is a manager or director at a 50-500 person company. They want a safe, proven solution that integrates with their existing stack. They buy with their LinkedIn profile.

A technical co-founder launching an internal tool as a SaaS for marketing teams needs to manufacture credibility from day one. Your launch is a performance designed to make your tiny company look like an established vendor.

Your Checklist:

1. Start your LinkedIn personal brand 4 weeks early. Post 2-3 times a week about the problem you solve. Not about your product. Share stats, helpful tips, and stories about the pain point. By launch day, your network should see you as an expert on the topic. Your launch post will feel like a natural next step, not a random ad.
2. Announce 5 partner integrations on day one. Your product doesn't live in a vacuum. Announce you integrate with Slack, Google Drive, HubSpot, Salesforce, and Zapier even if they're just simple webhooks. Put their logos on your homepage. It signals you understand your customer's workflow.
3. Get listed in 2-3 niche directories before launch. Submit your profile to G2, Capterra, and any industry-specific directories. You won't have reviews yet, but just being listed provides a huge trust signal for a B2B buyer doing their due diligence.

What to Skip: Anonymity. Your face and name need to be all over this. Don't hide behind a brand account. B2B buyers in this space buy from people they trust.

A Quick Comparison

What to do this week: Stop thinking about launching everywhere. Pick the one ICP profile from the list above that's closest to you. Write down its primary launch channel and its most important "skip" item on a sticky note. Put it on your monitor. That's your new launch plan. Your chances of success just went up because you're finally focused on what matters.