Website prelaunch tasks

Tutorials teach you how to build the thing. Almost none of them teach you what to check before real users touch it. Here’s the list I run through before launching a small website, split into the basics and the lessons that only showed up once real traffic and real money were involved.

Part 1: The basics

1. Hunt down fake data

Placeholder phone numbers, made-up ratings, stock addresses, lorem ipsum images. They sneak in, especially when AI tools generate your UI. My rule: if something shows on screen, it must come from a real database column. No data? Show an empty state, not a fake one.

2. Never trust the frontend

Hiding a button isn’t security. If you use Supabase or Postgres, turn on Row Level Security and test your API as a different user. Assume anyone can call anything.

3. Secure your webhooks

Payment webhooks (Paystack, Stripe) must verify the signature before doing anything. Make them idempotent too: providers retry, and a double-processed webhook means a double-created order.

4. Prefer narrow actions over free-form edits

For admin tools, don’t give a “set status to anything” field. Build specific actions like cancel_order or reconcile_payment that enforce the rules and leave a trail. Less flexible, much safer.

5. Set up email properly

Use a real domain, not a Gmail address. Receive mail with something like Cloudflare Email Routing and send with a transactional service like Resend. Verify your domain (SPF/DKIM) or your emails will land in spam.

6. Test the unhappy paths

Everyone tests “user pays, order succeeds.” Also test: payment times out, the user closes the tab mid-checkout, a vendor declines, a location is missing. Production bugs live there.

7. Keep a decisions log

When you’re buried in open decisions, pick a sensible default, write it down, and move on. Review the log later. Waiting for the perfect answer costs more than a reversible wrong one.

Part 2: Lessons from real bugs

8. Your frontend and database will drift apart

A column gets renamed, a type changes from a number to text, and suddenly something that worked yesterday breaks in production. Regenerate your TypeScript types from the real database schema regularly instead of maintaining them by hand. When the types complain, that’s the system doing its job.

9. Plan for “missing row” cases

A user who hasn’t shared their location. An account that has never made an order. A worker who’s idle and has no status record. Code that assumes a row always exists will crash the first time it doesn’t. Ask of every query: what happens if this returns nothing?

10. Money flows are state machines, not functions

“Accept, then pay within 15 minutes, then payout after 7 days” is not one function. It’s a set of states with timers and rules for what happens when time runs out. Write the states and transitions on paper first, then code them. Most payment bugs come from states you forgot to define.

11. Put test accounts and exceptions in config, not code

Need a test user to receive every request, or one account exempted from a rule? Store that in a config table or environment setting instead of hardcoding an if (user === "test") in your logic. Hardcoded exceptions get forgotten and ship to production.

12. Third-party APIs get retired

Maps, auth and email providers deprecate old endpoints and force migrations. Subscribe to their changelogs, and keep integrations behind one small module in your code so a migration touches one file, not fifty.

13. Social login needs legal pages

Google and Facebook login can work in development, but going live often requires a privacy policy and terms of service. The consent screen may also show your raw project URL until you set up branding. Budget time for this, because it’s not a code problem and it can block launch.

14. Working with several AI agents? Cross-check them

If more than one AI tool touches the same database or codebase, they will make conflicting assumptions. Treat their output like a pull request from a new teammate: read it, verify it against the real schema, and never assume it knows what the other agent changed.

Bonus: UI polish that users notice

“It looks too basic” is common feedback on a first version. The cheapest wins are not new features: use one consistent icon style, hide carousels and sections when there are only a few items, show useful details on cards (name, distance, time), and design real empty states.

Final tip: Launch small, watch real usage, and fix what actually breaks. A live site with real users teaches you more than another week of polishing.

What’s on your pre-launch checklist? Share it in the comments.