DEV Community

Cover image for “But it worked on my machine.”
Chenwi Edna
Chenwi Edna

Posted on

“But it worked on my machine.”

But it worked on my machine.”

That was the answer. Not the solution.

A friend pushed his feature to production. Everything had passed locally.

No errors.
No issues.

Then it went live.And immediately, Something broke.

The problem

The system wasn’t the same. What was happening?

In development:

• fewer users
• clean data
• no real traffic
• minimal concurrency

In production:

• real users
• messy data
• high traffic
• race conditions
• network delays

Same code.
Different reality.

Why this is dangerous

Local success gives false confidence.

Because you’re testing in a controlled environment.

But production…

Is unpredictable. That’s where systems are truly tested.

The solution

Don’t just test code. Test conditions.

Real systems prepare for production by:

• using staging environments that mirror production
• testing with realistic data and load
• simulating failures (timeouts, retries, delays)
• designing for concurrency and edge cases

The goal is simple:

Make production less surprising.

Mental model

Testing locally is like practicing alone.

Production is performing on stage.

Different pressure.

Different outcomes.

The lesson

If it only works locally… It doesn’t really work.

Takeaway

Reliable systems aren’t built in perfect environments, They’re designed for imperfect ones.

Have you ever deployed something that worked locally… but failed in production?

Top comments (0)