Saved
*The Bug That Saved a Company*
In 2019, a small fintech startup called RelayPay was 48 hours from running out of money. They had 3 engineers, one product, and one big client about to sign a $2M contract.
The night before the demo, their lead engineer Maya pushed a fix at 2 AM. She was exhausted. She meant to change one line: `timeout = 5000` to `timeout = 50000`. Instead, she typed `timeout = 5000`. No extra zero.
The bug meant every API call would fail after 5 seconds instead of 50.
The next morning, the client ran the demo. It crashed immediately. The CEO was furious. The client walked out.
Maya thought she’d killed the company.
But 20 minutes later, the client’s CTO called back. “What did you just change?” he asked. “We’ve been testing 12 vendors for 6 months. Yours is the only one that failed fast and gave us a clean error message. Everyone else hung for 2 minutes and locked up our system.”
He explained: in fintech, a slow failure is worse than a fast one. If a payment hangs, it ties up money, creates duplicate charges, and triggers fraud alerts. A fast failure lets the system retry instantly.
RelayPay’s “broken” demo revealed a design principle the bigger competitors had missed. The CTO rewrote their requirements to demand “fail fast” behavior. And he signed with RelayPay.
The bug that was supposed to kill them became their selling point.
Maya’s 2 AM typo got framed and hung in their office with the caption: “This is why we test in production.”
*Moral*: In tech, failure modes matter more than uptime. A system that fails fast, clearly, and safely will beat a system that pretends to be perfect until it silently breaks.
Want me to tell you another one about how a 1-line code change fixed Google’s search for 40% of the world?
