Somewhere in our repositories lives a project called Horiizon. It was going to be great. A Vue application, clean interface, designed to show what everyone in the company was working on at any given moment. Capacity planning, cross-team awareness, a living map of all the tech stacks currently in play. We built it, styled it, demoed it internally. And then... nothing. It sits there still, technically functional, gathering dust.
Horiizon isn't unique. We have a small graveyard of internal tools that solved real problems, looked promising, and quietly died anyway.
Some were one-offs. A script to automate something tedious, written fast because we needed it Tuesday. It worked. We moved on. Six months later, a similar problem surfaced and nobody remembered the script existed. Or they remembered, but without someone actively championing it, the tool just quietly faded from use.
Some were learning projects. We wanted to try a new framework, so we built something useful with it. The learning happened. The polish didn't. It worked well enough to prove the concept, but not well enough that anyone actually wanted to use it daily.
And some, like Horiizon, were genuinely good ideas that got stranded. We built a prototype, gathered feedback, had plans for the next iteration. Then a client deadline hit. Then another. By the time we came up for air, the dependencies were outdated and the momentum was gone. Starting over felt easier than catching up, so we did neither.
We think about this more than we used to. Not because we've solved it, but because we've started noticing the pattern earlier. When someone proposes a new internal tool now, we try to ask uncomfortable questions upfront: Are we building this to last, or just to learn? Do we have someone who'll own it six months from now? Is this solving a problem we'll still have next year?
We don't always get it right. Horiizon is proof of that. But maybe the practice isn't building perfect tools. Maybe it's just getting better at recognizing which ones deserve to survive.