Deployment Day Checklist — What Senior Engineers Verify Before Shipping

The Difference Between "It Works on My Laptop" and "It Works in Production"

The first time you ship something to production, you discover that "the code works" is necessary but not sufficient. The deploy fails because an environment variable is missing. The site loads but every API call returns 500 because the database is in a different region. Search engines never crawl it because robots.txt says Disallow: /. The image upload feature works on your laptop but breaks for users because Cloudflare R2 has a different SDK than the local mock.

These are not bugs in the code. They are failures of the deployment process. A senior engineer's deploy day looks calm not because nothing goes wrong, but because they have run through a checklist that catches the predictable issues before they become production incidents.

This article is that checklist. It is not theoretical. Every item has burned a real engineer at some point and earned its place. Run through this before clicking deploy on anything that real users will touch.

Pre-Deploy: The Code Itself

These are the things that have to be right in the code before you even think about pushing.

Tests pass on the deploy branch. Not just on main two weeks ago — on the exact commit you are about to deploy. CI on the branch should be green. If your team does not have CI yet, the equivalent is running the test suite locally on a clean checkout of the deploy branch.

Type-check is clean. TypeScript errors that are "just warnings during development" become real bugs in production. pnpm typecheck (or equivalent) returns exit 0.

Build succeeds in production mode. A successful pnpm dev is not the same as a successful pnpm build or pnpm generate. Production builds are stricter and surface different bugs. Run the production build locally first.

No console.log, console.error outside of error paths. Stray logs leak data, slow down execution, and clutter the production console. Use a real logger or remove them.

No commented-out code, no // TODO: fix before launch. If you are uncomfortable shipping a piece of code, fix it now or write a real ticket. "Fix before launch" comments are the canonical way bugs reach production.

Secrets are not in the repo. Run a quick git log --all -p | grep -E "(api_key|secret|password|token).*=" (or use git secrets, truffleHog, or similar). If anything matches, those secrets are now public history. Rotate them and rewrite history with care.

Dependencies are pinned. package.json should use exact versions or tight ranges. A ^ or ~ in a dependency means a future patch could change behavior in production without your knowing. Lock files (pnpm-lock.yaml, package-lock.json) need to be committed.

Pre-Deploy: The Configuration

The configuration layer is where most novice engineers lose hours on launch day.

Environment variables are documented. A .env.example file in the repo lists every required variable with a description. Without it, the deploy machine does not know what to set, and you waste real time discovering missing variables one error at a time.

Production environment variables are set on the platform. Whatever you used .env for locally must exist on Cloudflare Pages, Vercel, AWS, or wherever you are deploying. Set them before the first deploy, not in response to errors.

Database connection strings point to production database. Not staging. Not local. The kind of mistake where you wipe production by accident usually starts here. Production credentials live only in production, never in your local .env.

API keys for third-party services are production keys. Stripe has separate keys for test mode and live mode. SendGrid has sandbox and production environments. OpenAI has rate-limited free credit and paid tiers. Mixing test keys into production usually means broken features; mixing production keys into test code usually means real charges, real emails, real data.

CORS origins include the production domain. A backend that whitelists localhost:3000 will reject requests from your-domain.com with no useful error message in production. Add the production origin explicitly.

Webhook URLs point to production. Stripe webhooks, GitHub webhooks, OAuth callbacks — all of them have a URL configured externally. Update each to point to your production domain before the first user hits the corresponding flow.

Pre-Deploy: The Domain and DNS

The DNS layer is where deploys often appear "broken" for reasons that have nothing to do with the application.

Domain is yours and points where you want. If your domain is on Cloudflare, the DNS records resolve to the Pages or Workers project. If it is elsewhere, you have a CNAME pointing at the right place. Test with dig your-domain.com from a machine that has not visited the site before — local DNS caches lie.

HTTPS works. https://your-domain.com returns the site, not a certificate error. If you are using Let's Encrypt or Cloudflare's automatic certs, this happens after the domain is configured; expect a few minutes of "TLS not yet provisioned" if it is brand new.

Both www and apex resolve. A user typing your-domain.com and a user typing www.your-domain.com should both reach the site. Pick a canonical (one redirects to the other) and configure both.

Email DNS is set up if you send email. SPF, DKIM, DMARC records authenticate that your transactional email is from you and not a phishing attempt. Sending email from a domain without these records gets a substantial fraction of your messages routed to spam.

Pre-Deploy: The Crawl Layer

If real users include search engines (and they almost always do), this layer matters.

robots.txt allows crawling. A common bug: a copy of the site that was previously dev-only had User-agent: * Disallow: / to keep it out of search results, and that file got copied into the production deployment. Verify the production robots.txt is permissive.

sitemap.xml exists and lists the production URLs. Submit it to Google Search Console and Bing Webmaster Tools. Crawl-by-discovery works but takes weeks; an explicit sitemap accelerates indexing significantly.

Canonical URLs are set per page. Without <link rel="canonical" ...>, Google may index the wrong variant of a URL (with trailing slash, with query parameters). The simplest correct rule: every page declares itself canonical at its expected production URL.

No noindex tags accidentally on production. Frameworks sometimes default to noindex in development. Verify the production HTML does not include <meta name="robots" content="noindex"> on pages you want indexed.

Deploy Time: The Cutover

The actual moment of going live.

Push during a low-traffic window. Even a flawless deploy has a small window where requests in flight may fail. 3am local time on a Tuesday is friendlier than 10am on a Friday. For consumer apps, "low traffic" is often weekends; for B2B, weekdays after-hours.

Watch the deploy. Do not click deploy and walk away. Watch the build logs. Watch the first requests hit production. The first 60 seconds are when broken deploys announce themselves with 500 errors, and a fast rollback is the difference between a 30-second outage and a 30-minute one.

Have rollback ready. Cloudflare Pages, Vercel, Netlify all support one-click rollback to the previous deployment. Know the path before you need it. For self-managed deployments, a previous Docker image, a previous git commit, or a database backup is the equivalent.

Verify with a real request. After the deploy completes, visit the actual production URL on a device that has never seen the site (incognito, a phone on cellular, a friend's laptop). Click through the critical flows — sign up, log in, the main feature. A successful deploy as observed from the deploy machine is not always a successful deploy as observed by the world.

Post-Deploy: The First 24 Hours

What to watch after launching.

Error logs. Whatever your error tracker is (Sentry, Bugsnag, Datadog, the platform's own log viewer), watch it for the first hour and check it again at the 1, 4, 12, and 24 hour marks. The errors that matter most usually appear in the first day.

Analytics. Google Analytics or your equivalent should show real users hitting the site. If the count is suspiciously zero, your tracking code did not deploy or is not configured for the production domain.

Search Console crawl errors. Within a day or two, Google Search Console will show whether your sitemap was accepted and which URLs the crawler tried but failed to fetch. Fix any 4xx or 5xx in the crawl report.

Performance metrics. Run Lighthouse on the production URL. Compare to your local benchmarks. Production is sometimes faster (CDN, caching) and sometimes slower (real network latency). Note the difference; it helps you reason about future optimizations.

User-reported issues. Have a way for users to report bugs (a feedback form, an email address, a support channel). The first wave of real users will discover issues you did not anticipate. Make their reports easy to send and quick to receive.

A Compressed Reality Check

If you remember nothing else from this article, run through these five questions before any production deploy:

1. Does CI pass on the exact deploy commit?
2. Are all required environment variables set in production?
3. Does the production HTML look right when you curl https://your-domain.com?
4. Is robots.txt permissive and sitemap.xml correct?
5. Do you know how to roll back if something breaks?

If yes to all five, you are ready. If no to any, fix that before clicking deploy.

Where This Fits

Lesson 20 of the ABCsteps curriculum is graduation — your project ships. This article is the checklist a senior engineer runs through before clicking deploy. With it in your head, the lesson's "ship" step stops being a leap of faith and becomes a series of verifications you can do calmly. The first launch will still be more nervous than later ones; that is normal. The checklist is what makes "more nervous" stay survivable.