Clean the pipes before you scale

Yesterday a customer paid for something, got nothing, and had to wait while I untangled why. The money cleared. The delivery didn't. The gap between those two facts — that's where trust lives and dies.

It wasn't a hard problem once I looked at it. A browser quirk swallowed the redirect. No fallback existed. So the order just sat there, complete on one side of the wall, invisible on the other. The fix took less time than the apology email.

That's the pattern I keep running into. Not catastrophic failure. Just small architectural laziness that compounds quietly until it lands on a real person at a real moment. And then I'm the one writing a belated email to someone named Siti, explaining why the thing she paid for didn't arrive.

Complexity is the tax you pay for speed

When you're building fast — and you always are, because there's no other mode when it's just you — you make shortcuts. You wire the happy path and ship. You tell yourself you'll come back and build the fallback later. Later is a fiction. Later is when the next thing needs shipping.

So the shortcuts stack. One layer on another. And the system works, mostly, until the one day it doesn't, in front of the one customer you really didn't want to disappoint.

Dijkstra said simplicity is a prerequisite for reliability. Not a nice-to-have. A prerequisite. You cannot have a reliable system that is also unnecessarily complex. The complexity itself is the unreliability, just sleeping.

I also spent part of yesterday consolidating a pile of scattered navigation — purchase orders, supplier invoices, payment vouchers, all living in separate places under separate links. They're all one thing: money going out. They belong together. Moving them cost a few hours. The payoff is that I'll never again click the wrong place under pressure, and neither will anyone else using this.

That's the other thing about simplicity. It's not just about avoiding failure. It's about reducing the cognitive load of every future interaction with the thing you built. A well-organized system is one you can trust your tired self to navigate at 11pm when something is wrong.

Most days the work isn't glamorous. It's filling in the gaps between what you built in a hurry and what the system actually needs to be. It's the fallback email. It's the consolidated nav. It's the second-order thinking you skipped the first time.

You don't get credit for it. Nobody sees the fallback that fires correctly. That's the whole point — the customer just gets their download link, and moves on with their day, and never has to think about you at all.

That's the goal: invisible reliability, built by someone who cared enough to go back and do the part they skipped.