5 Deployment Mistakes That Cost Me Hours (And How to Avoid Them)

January 11, 2026 6 min read

I've deployed hundreds of applications to production. And I've made every mistake in the book. Here are the 5 most painful ones—and how you can avoid them.

Mistake #1: Forgetting CloudFront Cache Invalidation

⏰ Time Wasted: 3 hours

What Happened:

I deployed a critical bug fix to my Astro site on AWS. The build succeeded, files uploaded to S3, everything looked perfect. But when I checked the live site... the bug was still there.

I spent 3 hours debugging, rebuilding, checking S3 permissions, before I realized: CloudFront was serving cached content.

The Fix:

Always include CloudFront invalidation in your deployment workflow:

- name: Invalidate CloudFront cache run: | aws cloudfront create-invalidation \ --distribution-id ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }} \ --paths "/*"

Pro tip: CloudFront invalidations are free for the first 1,000 paths per month. Use /* to invalidate everything.

Mistake #2: Hardcoding Environment Variables

⏰ Time Wasted: 2 hours + security incident

What Happened:

I was in a hurry to deploy a Next.js app. Instead of properly setting up environment variables, I hardcoded the API key directly in the code. "I'll fix it later," I thought.

Two weeks later, I pushed to a public GitHub repo. Within 30 minutes, someone found the API key and racked up $400 in charges on my account.

The Fix:

NEVER hardcode secrets. Use environment variables and GitHub Secrets:

// ❌ NEVER do this const API_KEY = "sk_live_abc123..."; // ✅ Always do this const API_KEY = process.env.API_KEY;

And in your GitHub Actions workflow:

- name: Build env: API_KEY: ${{ secrets.API_KEY }} run: npm run build

Lesson learned: Security isn't something you "fix later." It's something you do right from the start.

Mistake #3: Not Testing Build Locally First

⏰ Time Wasted: 4 hours

What Happened:

I made a "small change" to my React app and pushed directly to production. The GitHub Actions build failed. I fixed the error, pushed again. Failed again. After 10 failed builds and 4 hours, I discovered the issue: a missing dependency that worked locally but not in CI.

The Fix:

Always run a production build locally before pushing:

# Test the production build locally npm run build # If using Docker, test the container docker build -t myapp . docker run -p 3000:3000 myapp

Pro tip: Create a pre-push git hook that runs the build automatically. It'll save you from embarrassing failed deployments.

Mistake #4: Ignoring Build Size Limits

⏰ Time Wasted: 6 hours

What Happened:

I deployed a Next.js app to Vercel. Everything worked great... until I added a few npm packages. Suddenly, my serverless functions started timing out. The culprit? My bundle size had ballooned to 50MB, exceeding Vercel's limits.

The Fix:

Monitor your bundle size and optimize aggressively:

# Analyze your bundle npm install @next/bundle-analyzer ANALYZE=true npm run build

Platform limits to know:

Mistake #5: Not Setting Up Monitoring from Day One

⏰ Time Wasted: Countless hours + lost users

What Happened:

I deployed a Vue app to production. It worked perfectly during testing. Three days later, a user emailed: "Your site has been down for 2 days."

I had no monitoring, no alerts, no idea there was a problem. I lost users and credibility because I didn't know my site was broken.

The Fix:

Set up basic monitoring BEFORE you launch:

Minimum viable monitoring:

  1. Set up a free UptimeRobot check (pings your site every 5 minutes)
  2. Add Sentry for error tracking (takes 5 minutes)
  3. Configure email alerts for both

This takes 15 minutes to set up and will save you from embarrassing downtime.

Bonus Mistake: Not Having a Rollback Plan

What Happened:

I deployed a "quick fix" on a Friday afternoon. It broke the entire site. I had no rollback plan, no previous deployment saved, and spent my Friday night frantically reverting commits and rebuilding.

The Fix:

Always have a rollback strategy:

Golden rule: Never deploy on Friday afternoon. If something breaks, you'll spend your weekend fixing it.

The Common Thread

Looking back at all these mistakes, they share a common theme: I was rushing.

I skipped steps to save time, only to waste hours (or days) fixing preventable problems.

The Real Solution:

Build a deployment checklist you run through every time. Include cache invalidation, env var verification, a local build test, and a rollback plan. The 5 minutes it takes saves hours of debugging.

Your Turn

What deployment mistakes have you made? I'd love to hear your horror stories (and solutions). Get in touch and I might feature them in a future post.

Deploy smarter, not harder.