When the cracks show up together

Yesterday I spent most of the day fixing things that were already broken.

Not broken in the obvious way — not crashed, not unusable. Broken in the way that only becomes visible when a real customer bumps into a real edge. Someone pays and never gets a receipt. Someone's card renewal fails and nobody tells them. Someone completes a checkout inside a restricted browser and the money leaves their account but the confirmation never arrives.

Each of these is a small thing. Individually, forgivable. Together, they form a portrait of a product that was built fast and never fully hardened.

I know exactly how it happened. Early on, you make a decision: ship now, fix later. That's usually the right call. Getting something in front of customers matters more than getting it perfect. The danger isn't the decision — it's forgetting you made it. The debt goes on the ledger whether you write it down or not.

The bill always comes

What I've noticed is that technical debt and operational debt behave the same way. They don't arrive evenly, one problem per week, spaced out for your convenience. They cluster. One customer complaint surfaces an issue. You investigate. You find three more things wrong underneath it. You fix those and discover a fourth problem adjacent to the third.

This is not bad luck. This is what deferred maintenance looks like when you finally pay attention to a system.

The right response is not to feel behind. The right response is to recognize you're doing the work that makes the business real — not just functional, but durable. There's a version of a business that technically works and a version that actually works. The gap between them is a long list of small things nobody noticed until they did.

Pieter Levels once said you don't need a co-founder, you need a customer. I think about that a lot on days like yesterday. Because the customers — the woman who paid via Apple Pay and never got her confirmation, the subscribers whose renewals silently declined — they didn't file a bug report. They just had a bad experience. The work of hardening a product is fundamentally an act of respect for those people. You're saying: I noticed what happened to you, and I'm making sure it doesn't happen to the next person.

There's no glory in it. Nobody applauds a webhook handler. But a business that holds together when it's stressed is a different animal than one that only performs when everything goes right.

Most of building a business is this: noticing the cracks, deciding they matter, and going back to fill them when you finally have evidence that you should.

The evidence was always there. You just needed a customer to show you where to look.