Most Internal Tools Die in Month Two

Not from neglect. From arithmetic.

The tool gets built, it works, and then it turns out the tedious way was cheaper all along. Cheaper than the tool plus its upkeep, plus the small tax of remembering the tool exists. So people drift back to the tedious way, and nobody announces it.

That is why the graveyard is full. Not laziness, not bad code. The problem was never big enough to beat the cost of solving it.

We wrote about Shrtnr earlier this year. It is our own URL shortener: self-hosted, open source, running on Cloudflare Workers. We built it because none of the paid ones let an AI agent create a link on its own.

It runs every link we publish. This article has seven. That is not luck, and it is worth being precise about why.

The arithmetic that decides it

Before you build anything internal, there are two numbers.

What the manual way costs: how often you hit the friction, multiplied by how much it hurts each time.

What the tool costs: the build, the upkeep, and the term everyone forgets, the cost of actually using the thing. Opening a tab. Logging in again. Remembering the slug convention.

Most internal tools lose on that third term, not the second. They work perfectly and still lose, because a tool that needs its own habit is competing against a habit you already have.

So the test is not "can we build this." It is not even "will we maintain it." It is whether the manual way is genuinely worse once the tool's own overhead is on the table.

Why this one wins it

The friction recurs. We publish constantly, and every article, post and campaign needs links we can measure. This is not an annoyance we hit twice a year. It happens every single time. Frequency is what makes a small friction worth engineering away.

Using it costs nothing. Shrtnr ships with an MCP endpoint, so the assistant we already write with creates the links inline, while the sentence is being written. Nobody opens a dashboard. Nobody copies a slug into a document. The cost of use rounds to zero, which is the only way a tool beats pasting a URL and moving on.

There is nothing to keep alive. It runs on Cloudflare Workers with D1, and we put KV in front of the redirect path. No server, no container, no patch cycle. It sits in the free tier, and a redirect comes back in one to five milliseconds from whichever of Cloudflare's 300+ edge locations is closest to the person clicking. A tool with no operational surface has no upkeep to lose to.

Three terms, all of them favorable. That is not a happy accident. It is what we checked before we started.

The feature that did not pass

We built click analytics in at the same time, and did not open them for two months.

Same tool, two features, one honest verdict. The redirects solved something we felt every day. The analytics solved something we thought we wanted. The arithmetic that kept the shortener alive is the same arithmetic that put the dashboard to sleep, and it makes the point better than any argument.

They earn their keep now, because a real question turned up: we wanted to know which articles get forwarded rather than just read. The feature started getting used the same week the question did.

What we do with it

We build software for other people for a living, so we are biased toward building. The discipline is not resisting that. It is running the numbers first, and being willing to say the boring answer out loud. Pay for the subscription. Keep the tedious way. This one is not worth it.

When it is worth it, build it properly, put it on the same board as client work, and expect it to still be running in a year. That is the standard, and it is the reason this one is still here.

Shrtnr is open source under Apache 2.0, it costs us nothing to run, and the project page has a one-click deploy if you want your own.

If you want a team that runs that calculation before it writes the first line of code, we are easy to reach.