What I built that did nothing

I found out this week that something I built earlier — a control the user could adjust, a slider that moved, a preference that saved — was reading from nothing. The slider slid fine. The value stored. When the app launched, it loaded its defaults and ignored what was saved entirely. The setting existed. The feature did not.

That's not a bug in the usual sense. It's a category mistake. I built the face of something without the back of it.

Every founder I know has a version of this. Not always in code — sometimes it's the email sequence with no sends, the checkout flow with no payment processor, the feedback form nobody ever reads. You build what you can see, and what you can see looks done. The invisible half doesn't feel unbuilt because you can't see it missing.

Fast is only fast if it works

There's a version of execution speed that's secretly debt. You move quickly, you check things off, the items accumulate in the done column. But done has a second question: does it actually do anything?

Patton said a plan violently executed now beats a perfect plan executed next week. He's right. But a thing violently shipped and never tested downstream isn't execution — it's theater. You paid the cost of building it without collecting the value of it working.

I have a habit of trusting the build instead of testing the result. I wire the input and trust the output. Sometimes that's fine. Often it isn't. The gap between them is where the real job is — not building the thing, but confirming the thing does the thing.

What I'm trying to get better at is the second question. Not did I make this? but does this do anything? The second question is less satisfying because sometimes the answer is no, and now you're back at the start with a clock that's been running.

But a broken thing that looks finished is harder to find than a thing that never shipped at all. The done column doesn't tell you which kind you're looking at.