The Launch Checklist

Adding auth to a live app means migrating user data, rewriting session handling, and checking every route. We use NextAuth across our projects - it is free and you control it. But the tool matters less than the decision: pick your auth approach before your first API route.

We started one project with Prisma, another with Drizzle. Different ORMs, different patterns, different maintenance burden. The ORM can be changed later - the database underneath cannot. Use Postgres everywhere unless you have a specific reason not to.

Without RLS, every query can potentially access every row in every table. AI coding tools generate Supabase code without RLS policies by default. Enable it on every table before your first query - not after someone accesses data they should not see.

If you hard-delete user data, it is gone forever. No undo, no audit trail, no GDPR compliance. We built a 30-day grace period with cascade deletion from day one. Adding that to a live database with real user data across multiple tables is a significant refactor.

You cannot migrate active subscriptions between providers. We were accepted by one provider, then blocked twice without warning. Another declined us because of our jurisdiction. A third had minimum transaction fees that ate into small subscriptions. Check three things before you commit: do they accept your jurisdiction, do they require a registered business, and what do their fees actually cost on YOUR transaction size - not the example in their marketing.

EU users can legally demand you delete all their data. If your schema was not designed for cascade deletion, responding to that request means manually hunting through every table. Design it so one delete command removes everything related to a user.

We set ours up early but still lost data by not filtering test traffic. Your own visits pollute your numbers. Set up analytics AND filter your own traffic before you go live - not after. Every day without it is user behaviour you will never see.

We shipped without it for too long. The bug that costs you your first paying customer is the one you never knew about. Errors in production are silent without monitoring.

We started using git mostly for backups. That is fine - you do not need to understand branching on day one. You need git init before your first file, git commit regularly, and git push to somewhere that is not your laptop. If your hard drive dies tomorrow, can you recover your project?

Trivial at setup - if you are using any modern hosting panel, it is a checkbox. Painful to retrofit because of mixed content warnings, hardcoded HTTP URLs, and broken embeds. Every browser warns users about non-HTTPS sites. Do it first.

Legally required before collecting any data or accepting payments. GDPR, CCPA, and every payment provider require them. They do not need to be long. They need to be honest.

These DNS records determine whether your emails reach inboxes or spam. Setting them up after your domain has a spam reputation is an uphill battle. We learned to separate business email from transactional email from day one - they are different tools for different jobs. Also: check your provider will actually let you send. We configured everything on one provider only to be trapped in their sandbox with no way out.

API keys in source code end up in git history forever. Even after deleting the file, the secret lives in every clone, every fork, every backup. Set up a pre-commit hook that scans for secrets before they reach git. It takes five minutes and catches mistakes you will definitely make. We know from experience.