How you handle failures is the difference

Years ago, a boss came out with a line that sounded like a provocation at the time: most developers aren't that different from one another; the real difference in a company is how it handles failures, not how it writes code. In a room full of people who made a living from writing code, it didn't go down well. Today it sounds like a prophecy.

Why it sounds like a prophecy today

AI has made cheap what used to be expensive: solving code problems. The answer to almost any programming error is one question away, and the gap between an average developer and a brilliant one, in the part of the job that is typing out solutions, has narrowed. That isn't bad news: it's the leveling of a skill that used to cost a lot of money.

Careful, though: that doesn't make developers interchangeable. What AI doesn't level is judgment: knowing what to ask, recognizing a bad answer when it arrives sounding confident, and above all deciding what deserves to be built. The boss's line wasn't against programmers: it was in favor of the part of the work that never shows up in a demo.

But if the typing part levels out, the question changes: what is left to tell one team from another? Exactly what that line pointed at. The things that were never code.

The things that were never code

Handling a traffic spike without the system going down, because someone decided at design time what happens when a thousand people show up at once. Finding out about an incident before your customer does, because there is an alert that fires on its own. Knowing who gets that alert, through which channel and what they are expected to do. Deciding which failures wake someone up and which can wait until Monday. Keeping a record that tells you what happened, instead of piecing it together from people's memories.

None of that gets solved by asking a chatbot once things are already on fire. These are decisions made when the system is designed, they cost little at that point, and they show up years later, almost always on a bad day. Their absence shows up too: it's the difference between a provider who calls to warn you and one you have to call to ask why nothing works.

Take any example: two online stores hit the same payment gateway failure on a Friday at eleven at night. In one, the system retries the charge, sends an alert through the agreed channel, and on Monday there is a list of affected orders with their status. In the other, on Monday there are emails from angry customers and a morning of digging through logs. The failure was identical. The difference was everything else.

The Saturday night question

That's why, of the six questions we suggest answering before asking for a software quote, the one that says the most about a project is the one nobody has thought about: if the system fails on a Saturday night, who wants to know, and what do they expect to happen? The answer separates an office tool from a system that keeps a business running, and it defines how much of that failure handling needs to be built. Any answer is legitimate; the expensive part is when nobody asked the question.

Our product exists because of this idea

Trackfinite, our SaaS for monitoring online stores, comes from exactly here: when a cart is left halfway, in most stores nobody knows whether the website, the payment or the customer failed, and the incident turns into an argument between departments. Putting data on that moment (what failed, when, and what it costs) is failure handling in its purest form, and we walk through its architecture decisions on our case studies page. It's no coincidence that the first thing we built with our method was precisely this.

All of this also leaves you with a new way to compare teams, now that everyone codes with the same tools: ask less about the tech stack and more about the bad day. What they monitor, which alerts fire and who receives them, what gets logged so you can reconstruct what happened. The answers to that tell teams apart today more than any trendy technology, because they are the ones that can't be improvised once you need them.

The conclusion isn't the fashionable one. It's not that AI changes everything: it's that, precisely because of AI, what matters now is what always mattered. Architecture that holds up, alerts that reach the people they should reach, and someone who thought about the bad day before it happened. That still doesn't come out of the box, it still sets one team apart from another, and it's still what we ask about on the first call. If you want us to think through your bad day with you, tell us about your project.