"It works on my machine" stopped being an environment problem years ago. Containers settled that. What's left is a cardinality problem.
Your machine has exactly one of everything.
One request in flight. One copy of each callback. One well-formed record. One clock.
Production guarantees none of that, and that's where code which passed locally starts producing wrong results instead of errors.
Three places I see it break, all of them invisible on a laptop:
Concurrency. Locally you are the only actor, so a read-then-write on a balance looks correct every time. Put two simultaneous requests through the same code and it credits twice, because nothing in it ever claimed a row before computing on it.
Delivery multiplicity. You fire the provider callback once, by hand. Real rails retry: on timeouts, on a 500 you returned after the write committed, on their own schedule. A handler that isn't safe to run twice is already broken. You just haven't been retried yet.
Data shape. A catalog parser written against one hand-picked product page is a parser tested on a sample size of one. At scale the fields go missing, prices show up in another format, stock values stop being numbers, and the parser quietly returns a shape nobody downstream validates.
So I stopped testing for environment parity and started testing for multiplicity. Replaying the same event twice is a standard test for me now, not an edge case. Two writers at the same row. The ugliest records I have going into the pipeline, not the cleanest.
What I want is code with no opinion about how many times, in what order, or in how many copies it runs. A laptop that matches production doesn't get me there.
I write up more of these production failure modes on my blog, if you want the longer form: https://polycratia.com/c/88a41cd1
Curious which of the three bit you hardest: concurrency, duplicate delivery, or data shape.