5 Mistakes I Made Deploying My First Production App

My first real production deploy had five distinct mistakes, each embarrassing in hindsight and each genuinely instructive. Writing them down mostly so I don't repeat them, and so maybe someone else skips one of these the first time around.

1. No environment variable validation

I typo'd an environment variable name in production. The app didn't crash — it silently fell back to undefined, which happened to be falsy enough to not immediately break anything, and the bug only surfaced when a feature depending on that variable quietly malfunctioned two days later. The fix I should've had from day one: validate required environment variables at startup and fail loudly and immediately if one's missing, instead of discovering it through a confused user report.

2. Testing exclusively against a seeded, empty-ish database

Every "it works" check was against a database with a handful of clean test rows. The first real user data hit an edge case — a name with an apostrophe, a null field my code assumed was always present — that a fuller, messier dataset would have caught before launch. Lesson: test against data that looks like production will actually look, not data that's convenient to set up.

3. No health checks, so I found out about downtime from a user

The app went down for eleven minutes and I found out because someone emailed asking if the site was broken. There was no monitoring, no alert, nothing watching the thing I'd just shipped. A basic uptime check, even a free one, would have told me before a user did — and that gap between "the app is down" and "I know the app is down" is the single most avoidable mistake on this list.

4. Deploying directly to production, no staging step

Every change went straight from my machine to the live app, because setting up a staging environment felt like extra work for a "small" project. The first time a deploy broke something, it broke it live, for real users, because there was no intermediate step where I could have caught it first.

5. Secrets committed to the repo, briefly, then "removed"

An API key ended up in a commit, got noticed, and got removed in a follow-up commit — except it was still sitting in git history, readable by anyone with repo access, until I rotated the key and properly scrubbed it. Removing a secret from the current file isn't removing it from the repo; it's still in every commit before that one.

Takeaway

None of these were exotic failures — they were all "should have known better" mistakes that are obvious in a list like this and invisible in the moment of shipping something for the first time. Writing them down is mostly so future-me, and anyone reading this before their own first deploy, doesn't have to learn all five the expensive way.