The Pre-Launch Checklist: 25 Things to Verify Before You Go Live

Every team has a launch-day story. The payment button that only worked in test mode. The password reset email that landed in spam. The app store rejection that cost a week. None of these problems were hard to fix. They were just hard to find at 11pm with users already on the site.

After shipping web, mobile, and AI products for clients, we’ve learned that launches rarely fail because of one big mistake. They fail because of a handful of small, boring things nobody checked. This checklist is our attempt to catch those things early.

Use it as a final gate before you go live. If you can honestly tick every item, you’re in good shape. If you can’t, you now know exactly what to fix first.

Part 1: Functionality and Quality

1. Test the core user journey end to end

Walk through the one thing your product exists to do, from sign-up to success, as a brand-new user. Do it on a fresh account, not your admin login. Why it matters: if the core journey breaks, nothing else counts.

2. Test on real devices and browsers

Emulators miss things. Check at least two or three real phones (include a low-end Android device), plus Chrome, Safari, and Firefox on desktop. Why it matters: many of your users will not have the latest flagship phone or a fast connection.

3. Check every form and validation message

Submit empty fields, wrong formats, very long text, and special characters. Confirm that error messages are clear and human. Why it matters: forms are where users give up.

4. Verify transactional emails and SMS

Sign-up confirmations, password resets, receipts, and OTP codes should all arrive quickly and not land in spam. Check SPF, DKIM, and DMARC on your sending domain. Why it matters: if users can’t verify or reset, they can’t get in.

5. Remove test data, placeholder text, and debug code

Search for “lorem ipsum,” “test,” “TODO,” and leftover console logs. Make sure no demo accounts with weak passwords remain in production. Why it matters: it protects both your credibility and your security.

Part 2: Performance

6. Measure page speed and app startup time

Run Lighthouse or PageSpeed Insights for web, and time cold starts for mobile. Aim for pages that feel usable in under three seconds on a mid-range phone. Why it matters: slow products lose users before they see any value.

7. Test on a slow connection

Throttle your network to 3G speeds and try again. Check that images are compressed and that the app fails gracefully when the connection drops. Why it matters: fast office Wi-Fi hides real-world problems.

8. Run a basic load test

You don’t need to simulate a million users. Simulate ten times your expected launch traffic with a tool like k6 or Locust and watch what breaks first. Why it matters: a successful launch announcement is the worst time to discover your server can’t cope.

Part 3: Security Basics

9. Force HTTPS everywhere

Confirm your SSL certificate is valid, set to auto-renew, and that HTTP redirects to HTTPS. Why it matters: browsers flag insecure sites, and users notice.

10. Lock down secrets and credentials

API keys, database passwords, and tokens belong in environment variables or a secrets manager, never in your code repository. Rotate any key that was ever committed. Why it matters: leaked keys are one of the most common causes of breaches and surprise cloud bills.

11. Review authentication and access control

Check password rules, rate limiting on login attempts, session expiry, and that users can only see their own data. Try changing an ID in a URL to see if you can view someone else’s record. Why it matters: broken access control is among the most common serious web vulnerabilities.

12. Protect against common attacks

Confirm that inputs are sanitized against SQL injection and cross-site scripting, and that your framework’s CSRF protection is on. Update dependencies with known vulnerabilities. Why it matters: automated bots start probing new sites within hours.

Part 4: Payments and Money

13. Run real payment tests

Test successful payments, failed payments, refunds, and cancelled transactions in sandbox mode, then make at least one small live transaction. If you support mobile money such as M-Pesa, test the full callback flow, including timeouts and duplicate confirmations. Why it matters: payment bugs are expensive and erode trust immediately.

14. Confirm webhooks and reconciliation

Make sure your system correctly handles delayed, repeated, or missing webhook events from your payment provider, and that your records match theirs. Why it matters: mismatched records turn into accounting headaches fast.

Part 5: Monitoring and Resilience

15. Set up error monitoring

Tools like Sentry or Bugsnag tell you when something breaks before users complain. Test that alerts actually reach the right people. Why it matters: you can’t fix what you can’t see.

16. Set up uptime monitoring and alerts

Use a simple service to ping your site and API every minute, and route alerts to a phone, not just an inbox. Why it matters: downtime at 3am should wake someone up, not wait until Monday.

17. Verify backups and test a restore

Automated backups are only useful if restoring from them works. Actually perform a restore on a test environment. Why it matters: many teams discover their backups are broken only when they need them.

18. Prepare a rollback plan

Decide in advance how you’ll revert a bad release: a tagged previous version, a database migration strategy, and a named person with authority to pull the trigger. Why it matters: a calm rollback beats a panicked patch.

Part 6: Analytics and Growth

19. Install analytics and define your key events

Track sign-ups, activation, purchases, and drop-off points. Confirm events fire correctly in both staging and production. Why it matters: without data, your first month of learning is wasted.

20. Set up SEO and sharing basics

Check page titles, meta descriptions, a sitemap, a robots.txt file that isn’t accidentally blocking everything, and social preview images. Why it matters: a staging “noindex” tag left on production is a classic launch-day mistake.

Part 7: Compliance and Store Readiness

21. Publish your legal pages

Privacy policy, terms of service, and cookie notice where required. If you collect personal data, make sure your policy matches what you actually do, including data protection obligations such as Kenya’s Data Protection Act or GDPR if you serve those users. Why it matters: app stores require it, and regulators expect it.

22. Meet app store requirements early

For mobile, prepare screenshots, descriptions, age ratings, privacy declarations, and test credentials for reviewers. Submit well ahead of launch, since reviews can take days and rejections are common. Why it matters: store review is the one deadline you don’t control.

23. Check accessibility basics

Ensure sufficient color contrast, readable font sizes, labelled buttons and inputs, and that the product can be navigated without a mouse. Why it matters: it widens your audience and reduces legal and usability risk.

Part 8: People and Process

24. Set up support channels and response owners

Decide where users will report problems (email, chat, WhatsApp) and who answers, with a target response time. Prepare a few canned replies for the questions you expect. Why it matters: early users who get fast help become your best advocates.

25. Plan launch day itself

Pick a launch time when the team is available, not Friday evening. Assign roles for monitoring, support, and communication, and agree on what “launch is going badly” looks like and what you’ll do about it. Why it matters: a plan turns panic into process.

How to Use This Checklist

Not every item carries equal weight for every product. A simple internal tool doesn’t need a load test; a fintech wallet needs nearly everything on this list. A good rule of thumb is to sort the items into three groups:

• Must fix before launch: anything involving payments, security, data loss, or the core user journey.

• Fix within the first week: polish, secondary performance gains, and accessibility improvements.

• Schedule for later: nice-to-haves that won’t hurt early users.

And remember that shipping is not the finish line. The best launches are followed by a week of close watching, quick fixes, and honest conversations with early users.

Ready to Launch With Confidence?

At Mergeden, we build web, mobile, and AI products with launch readiness baked in from the first sprint, so there are no last-minute surprises. Whether you’re scoping your first MVP or preparing to go live with an existing build, our team can review your product against this checklist and help you close the gaps.

Talk to the Mergeden team and let’s get your product shipped.