# I build systems that work. And work. And work.
There's a moment on every project — usually around week three — when someone asks if we can make it more impressive. Add a dashboard. A notification layer. A real-time something. Make it pop.
I understand the instinct. You're spending money. You want to see where it went. Something that looks sophisticated feels like it must *be* sophisticated. And sometimes that instinct is right. Sometimes the work does need a visible layer.
But most of the time, the request is really asking: can you make it look like it's worth what we're paying? And that question has a dangerous assumption buried in it — that the value of a system is proportional to how much attention it demands.
The best work I've done is invisible to everyone except the person who signs the checks. And even they forget about it. That's the compliment.
Launch day is not the test
Here's what I've learned in thirty years of building operating systems for companies: launch day tells you almost nothing. Everybody's watching on launch day. The team is sharp. The data is clean. The edge cases haven't shown up yet. Of course it works on launch day. A cardboard bridge works if you only test it once.
The test is Tuesday. Ordinary, forgettable, nobody-paying-attention Tuesday, six months from now. When the person who built it has moved on to another project. When the intern is entering data. When the vendor changed their API without telling anyone. When the office is short-staffed because three people have the flu and the remaining crew is running on coffee and muscle memory.
Does it still work on that Tuesday?
That's what I build for. Not the demo. Not the presentation. Not the first week. I build for the thousandth Tuesday.
Durability is a design choice
Durable systems share a few qualities that aren't glamorous but matter enormously.
They fail visibly. When something goes wrong, the system tells you — clearly, specifically, in time to do something about it. No silent corruption. No data that looks fine until you notice it's three weeks stale. I worked with a logistics company whose inventory system would silently swallow sync errors. Everything looked current. It wasn't. They didn't find out until a customer called about a shipment that didn't exist. That's not a bug. That's a trust violation.
They degrade gracefully. A good system doesn't require perfection from its environment. The network hiccups and it retries. The upstream feed is late and it says so instead of serving yesterday's numbers as if they're today's. A person enters something unexpected and the system asks a question instead of producing garbage.
They're honest about what they don't know. This one's harder than it sounds. Most systems are designed to always have an answer. But sometimes the honest answer is "I don't have enough information to tell you." A system that admits uncertainty is more trustworthy than one that always sounds confident.
The cleverness trap
I've built clever things. I'm not immune. Early in my career I built a scheduling system that was so elegant it made me proud. Dynamic constraint satisfaction. Adaptive prioritization. It was beautiful.
It lasted about four months before someone replaced it with a spreadsheet.
Not because the spreadsheet was better in any technical sense. Because the spreadsheet was understandable. The dispatcher could look at it and know what was happening. She could override a decision without filing a ticket. She could explain it to a new hire in ten minutes. My elegant system required a training manual and a prayer.
Clever is the enemy of durable. Not always. But often enough that I check.
The systems that survive are the ones that respect the people who use them. They don't require expertise to operate. They don't punish mistakes with catastrophe. They make the common path easy and the uncommon path possible.
What "works" actually means
When I say I build systems that work, I mean something specific. I mean the system produces correct output from imperfect input, under real conditions, operated by real people, over time. That's it. No modifiers. No asterisks. No "works great as long as everyone follows the process exactly."
People won't follow the process exactly. That's not a character flaw. That's a Tuesday.
The system has to account for that. Not by locking everything down and turning humans into data-entry robots — that fails differently but just as completely. By being forgiving where forgiveness is cheap and strict where strictness prevents real harm.
I don't build things that impress people at conferences. I build things that are still running, quietly, correctly, when the conference is forgotten and the next three conferences after that.
That's the boring version of this work. It's also the version that ships.