We all use mailpit or mailtrap in development. Nobody sends real emails locally. That issue has been resolved for a long time.
But email is the only problem we've solved. What about everything else? We just skip it.
Email validation
In production, your signup checks MX records and blocks disposable domains, among other things. In development, you type test@test.com and move on.
Here's the issue: someone owns test.com. They receive your test data. That address appears on over 1,500 blacklists because many developers use it.
MX validation usually can't run correctly in most development setups. The DNS lookups fail when offline, and they fail with fake domains. Symfony has an open issue about turning off checkMX in test environments for this reason. So the one piece of validation that really matters gets shipped completely untested.
Remember when HBO Max sent "Integration Test Email #1" to all their subscribers?
Regex
You know the workflow. You go to regex101, test a few strings, everything looks good, then you paste it into code, commit, and push. No unit tests, ever.
There's a library on GitHub called regex-tester. The whole message in the README is simple: "Because regular expressions are complex and error prone, and you probably don't unit test them." That's it. That's the main point. And honestly? That makes sense.
Character limits
You have a 120-character company_name column in your database, but there's no maxlength on the form. It works fine in development because you always type "Test Company." But it breaks in production when someone pastes their full legal entity name.
Microsoft added detailed truncation warnings as a key feature in SQL Server 2019 because the old error was so useless that no one could debug it. Emojis cut SMS limits from 160 to 70 characters. X's 280-character limit is really a byte limit that creates issues with multibyte characters. Entity Framework silently truncates without providing an error. This happens everywhere.
CORS
Locally, you run the frontend and backend on the same origin. You might throw Access-Control-Allow-Origin: * on everything, use a browser extension, or launch Chrome with --disable-web-security.
Then you deploy to real subdomains and spend your afternoon searching for CORS errors that didn't exist yesterday. I've seen senior developers waste an entire half-day on this. There's no straightforward way to test real cross-origin behavior locally.
SSL
We've all done it: curl -k, NODE_TLS_REJECT_UNAUTHORIZED=0, verify=False, CURLOPT_SSL_VERIFYPEER => false.
It always seems "temporary." But then it ends up in the Dockerfile, then staging, and next, someone copies that config to production. Now your app trusts every certificate out there.
So what
The Twelve-Factor App mentioned dev/prod parity back in 2011. We're still not following that advice.
Production has real validation, real security, and real constraints. Development runs on assumptions and test@test.com. The gap between the two is where your next production bug is hiding.
The mailpit pattern works for more than email. Use tools that give real results but cost nothing and stay out of your way. I built some free utility APIs for exactly this (apixies.io) but honestly it doesn't matter which tool. It matters that you stop skipping the check entirely.
If it only runs in production, it's not a check. It's a hope.
What's the dumbest prod bug you've shipped that a simple check in dev would've caught?
Top comments (0)