Retiring a thing you built
Killing your own work is not failure — it's the clearest sign you're still in charge.
Yesterday I deleted something I built. Not because it stopped working. Because I had built a better home for it, and the old address was just clutter now — a forwarding label on an empty apartment.
It took maybe ten minutes to clean up. But I sat with it for a moment before I did it. There's a specific feeling when you retire your own work. It doesn't hurt exactly. It's more like a small accounting. I made that. It served its purpose. Now it's done.
Founders are bad at this. We treat everything we built as evidence we exist. Deleting it feels like erasing a credential, like admitting the work was temporary. But all work is temporary. The question is whether you're the one deciding when it ends, or whether you're just too attached to notice it should have ended already.
The weight of what you keep
Every project you maintain is a recurring tax. Not a big one — sometimes it's just a subdomain sitting in a DNS panel, an old config file nobody reads, a feature that one person uses twice a year. Individually, nothing. Collectively, they are the reason your attention is always fractured when you sit down to do real work.
The mental overhead of keeping something is almost never zero. There's always a moment, somewhere in the week, where it surfaces. A login to check. A tab to close. A thing to remember when you're setting up something new. Small. But relentless.
I've been moving a few businesses toward cleaner foundations lately — not because they were broken, but because I could feel the drag of accumulated decisions I made two years ago when I knew less. Retiring old infrastructure, consolidating where things live, building the newer version in a way I actually understand now instead of a way I understood then.
None of it is glamorous. Nobody ships a press release about cleaning up. But I've noticed that every time I finish one of these sessions, the next real project moves faster. Not because I freed up server resources. Because I freed up the part of my brain that was quietly tracking all the old stuff.
Jeff Atwood once said the best code is no code at all. The same is true of decisions, dependencies, and old versions of your business. The best version of your stack — technical or otherwise — is the smallest one that still does the job.
Killing something you built is not a loss. It's proof you're not just a curator of your own past.