The Startup Deployment Checklist: Everything to Verify Before You Go Live

Most deployment failures come from missing something basic. Not complex architectural problems - just skipped steps that weren't obvious until everything broke.

This checklist exists because I've seen the same issues tank deployments dozens of times. Work through it before you deploy, and you'll avoid the problems that cost most founders hours of debugging.

Environment & Configuration

Every environment variable is documented somewhere. Your .env file has everything your app needs. Every API key, every database URL, every secret. Write them down in a secure note - you'll need to recreate this list in production.

You understand the difference between build-time and runtime variables. Some variables are needed when your app builds (like NEXT_PUBLIC_ prefixed vars in Next.js). Others are only needed when it runs. Getting this wrong causes confusing bugs where things work in one context but not another.

Sensitive values aren't in your repository. Check your git history. If you ever committed a .env file or hard-coded an API key, it's in your history even if you removed it later. This matters for security and for platforms that might expose your repo.

Your build command runs successfully on your machine. Run npm run build (or equivalent) locally. If it fails here, it will definitely fail in production. Fix all errors and warnings before proceeding.

Database

You have a production database URL. localhost:5432 doesn't count. You need an actual database service - whether that's Railway, Supabase, PlanetScale, or a managed database on your hosting provider.

Migrations are tested and ready. If your app uses database migrations, run them against a fresh database to verify they work. Migration failures in production are painful to debug.

Connection pooling is configured (if using serverless). Serverless functions open new database connections on each invocation. Without pooling, you can exhaust your connection limit quickly. Services like PgBouncer or Prisma's connection pooling help here.

Domain & DNS

You can log into your domain registrar. Sounds obvious, but verify you have the credentials to access your DNS settings. Recovering access can take days.

You know what DNS records you need. Most hosting platforms tell you exactly what to add - usually an A record (IP address) or CNAME record (hostname). Have this information ready before touching DNS settings.

TTL is set appropriately for your situation. While making changes, low TTL (300 seconds) lets you iterate quickly. Once stable, higher TTL (3600+) improves performance. Many people forget to lower TTL before making changes, then wonder why updates take forever.

You've decided on www vs non-www. Pick one as canonical and set up a redirect from the other. Having both live without redirects hurts SEO and can cause session issues.

Security & SSL

SSL certificate is sorted. Most platforms handle this automatically with Let's Encrypt. Verify it's enabled. A site without HTTPS will show browser warnings that immediately tank user trust.

HTTP redirects to HTTPS. This should be automatic, but test it by explicitly visiting http://yourdomain.com. It should redirect to the secure version.

No API keys in client-side code. Search your codebase for any secrets that might be exposed to the browser. These are visible to anyone who opens developer tools.

Hosting & Infrastructure

You have an account on your hosting platform. Created, verified, and payment method added if required. Hitting account issues mid-deployment is frustrating.

You've selected an appropriate tier. Understand what resources your app needs. Most MVPs run fine on the smallest tier, but CPU-intensive or memory-hungry apps might need more from the start.

You know how to deploy (and redeploy). Whether it's git push, CLI command, or clicking a button - make sure you understand the deployment mechanism before you need to use it in a hurry.

You have a rollback plan. If deployment goes wrong, how do you get back to a working state? Most platforms support instant rollbacks to previous deployments. Know where that button is.

The 80/20 Rule of Deployment

About 80% of deployment failures come from just a few categories: missing environment variables, database connection issues, and DNS misconfiguration. If you verify these thoroughly, you avoid most problems.

The remaining 20% are usually framework-specific or architecture-specific issues that require more targeted debugging. But getting the basics right first means you're only troubleshooting one category of problem instead of several.