Home Features For Vibe Coders For Developers Pricing Documentation Services Contact
← Back to blog

What I run before pushing a website to production

Every dev has their own checklist. Mine got long. Here it is, in the order I actually run it.

1. The build runs cleanly on a fresh checkout

rm -rf node_modules dist .next
pnpm install --frozen-lockfile
pnpm build

Half the time, “it works on my machine” is because something in your node_modules is from three months ago and stale. A fresh checkout build catches lockfile drift, cached compilations that hide TypeScript errors, and dependencies you forgot to add.

2. Type check with no implicit any

pnpm tsc --noEmit should produce zero output. If you have errors you’re “going to clean up later”, you’re going to ship a bug. Today.

3. The full test suite

Not “the tests for the files I changed”. The full suite. Vitest is fast. There’s no excuse.

4. Manual smoke test of the critical paths

Whatever your site does that earns money: log in, sign up, checkout, submit form. Click through it on the production build, locally. Not the dev server. The dev server lies. It has hot reload, error overlays, source maps, and verbose console output that production doesn’t.

For one of my projects this is exactly four flows. It takes 90 seconds. It has caught more bugs than all my unit tests combined.

5. Network panel: how big is the page?

Open DevTools, Network tab, hard reload. What’s the size? What’s the largest asset? Are there 404s? Is there a font you forgot to remove from a previous design?

I’ve shipped pages with 4MB of unused JavaScript because Next.js was bundling something I deleted. The build didn’t warn me. The network panel did.

6. Lighthouse for the regression check

Not for the score. For the diff against the previous deploy. If LCP went from 1.8s to 3.2s, find out why before you push.

7. CSP headers actually work

curl -I https://staging.example.com | grep -i content-security

If it’s missing, add it. If it’s default-src 'unsafe-inline' 'unsafe-eval' *, you don’t have a CSP. You have a placebo.

8. The 404 page exists

Hit a route that doesn’t exist. Make sure the 404 page renders correctly with nav and footer. I have shipped sites where the 404 page was the React app’s “loading” state, frozen forever, because the SPA fallback was misconfigured.

9. The error tracker is connected

Sentry, BugSnag, whatever you use. Throw a test error in staging. Confirm it shows up in the dashboard. If you can’t see your errors, you don’t have an error tracker.

10. Rollback plan in 30 seconds

Can I revert this deploy in under 30 seconds? On Vercel, yes, one click. On Netlify, yes. On a custom Cloudflare deploy with a 10-step pipeline, maybe not. Know your rollback before you ship, not after.

The actual lesson

Most of this list I now run with one command. The thing I learned: the boring checks catch the boring bugs, which are the ones that make your phone ring at midnight.

Join the feed

Get feature releases and engineering updates delivered to your inbox.