Free as in Puppy: The Real Cost of the Internal Tool You Built in a Weekend

1. The free puppy

A story went around social media earlier this year, in two parts, months apart.

Part one: someone at a startup, a QA lead rather than a developer, built the team their own project tracker. It was better than Jira. It was more detailed than Jira. The whole team dropped Jira, Linear and Trello and moved onto it.

Part two, posted later as an update: they had gone back to Linear, because maintaining the tool they built was eating into the bandwidth they needed for their actual work.

It is worth repeating because both halves are true at once, and most people who read it only remembered one half. The tool was good, by every account, and it stayed good. This is a story about a team finding out what they had agreed to.

The reply that stuck to it borrowed a phrase the software industry has used about open source for years: it was free as in puppy, not free as in beer. Free as in beer means you drink it and you are done. Free as in puppy means the acquisition cost was zero and the next eight years are yours.

That distinction used to apply to software you adopted. It now applies to software you generate, and it applies far more often, because the price of acquiring a puppy went to nothing.

2. What you actually took on

The weekend build is real. If you have shipped an internal tool this way you already know the software works, so nothing here is an argument that it doesn’t.

The weekend build has a purchase price of R0. It does not have a total cost of ownership of R0, and the second number is the one nobody works out.

Not the bugs, which you expect and which are the least of it. The obligations:

• The dependency treadmill. Your auth library ships a breaking change. Your hosting provider deprecates the runtime you are on. Nobody asked for this work, nobody gets credit for it, and skipping it for a year turns a two-hour upgrade into a two-week one.
• The outage that lands on a Wednesday. Linear going down is Linear’s problem and someone else’s weekend. Your tracker going down is your problem, during the sprint, while eleven people wait.
• The change that is small everywhere except here. The company adds SSO. Every vendor tool supports it out of the box. Yours needs someone to implement it.
• The person who leaves. The single most expensive line item, and the one nobody writes down. The tool works, and the only person who understood why it works that way is now at a different company. You are left with a codebase nobody chose, that everyone depends on, that no one wants to open.
• The data you cannot walk away from. Two years of tickets, decisions and history now live in a schema one person designed on a Sunday. Migrating off it is a project. That is not a hypothetical cost; it is the reason teams stay on tools they have already outgrown.

None of these are exotic. Every one of them is ordinary, and the ordinary ones are what accumulate.

3. Why it feels free right up until it doesn’t

Nobody here was careless. The two costs arrive in shapes you cannot compare.

You pay the cost of building once, in a visible block, and someone volunteered for it and enjoyed it. You pay the cost of owning in fifteen-minute interruptions, spread across two years, taken from whoever is nearest when it breaks. Only one of those ever forms a number in your head.

Worse, the two costs are compared on the wrong axis. The subscription you cancelled had a price on an invoice, so it looked like the expensive option. The tool you built has no invoice, so it looked free. But the subscription was the cheap one in the only currency that is scarce, which is the attention of the four people who build your product. A vendor tool converts engineering hours into rands, at a fixed rate, in advance. That is not a fee. That is the service.

This is the same asymmetry we wrote about in the new software economics, applied one level down. When building gets cheap, the scarce resource is not the building. It is the attention that has to be spent on everything the building created.

4. Sometimes the puppy is worth it

The obvious conclusion here is “don’t build internal tools,” and it is wrong.

Go back to the first half of that story. A QA lead built a tracker that beat Jira for his team’s workflow, and eleven people preferred using it. In 2021 that result was not available to him at any price. Something changed, and telling people to ignore it because maintenance exists is bad advice dressed as prudence.

Plenty of internal tools are worth owning. The script that saves your ops team six hours a week. The workflow so specific to how you operate that no vendor will ever build it, which is the category where off-the-shelf software makes you work in whatever way suits the software.

Plenty of others are not, and “pay the subscription” is a legitimate answer that gets treated as a failure of ambition. It isn’t one. Renting software you could build is how you decline to own it, and in a small team, declining to own things is most of what focus consists of.

So the failure is not building, and it is not who built it either. The “he isn’t even a developer” detail is the least interesting part of the story, because developer-built internal tools die the same death at the same rate.

The failure is that you priced an ongoing commitment as a one-off, because on the day, the one-off part was the only part you could see.

5. The variable is ownership, not authorship

Code quality matters. Badly built software costs more to keep alive than well built software, and anyone who has inherited a mess knows it. But code quality on its own does not predict which tools survive, because the well built ones get abandoned too. What separates them is whether anyone answered three questions before the first commit.

Who owns this in six months, by name? Not “the team.” A person, who knows they own it, whose manager knows they own it, and whose workload reflects it. A tool owned by everyone is owned by nobody, and it will be maintained on exactly that schedule.

What is the hourly budget, per month, and who is paying it out of what? Give it a number. Two hours a month, four, eight. The number matters less than the act of writing one down, because that is the moment the comparison becomes honest. Eight hours a month against a subscription price is a real decision. Zero against a subscription price is not a decision, it is an oversight.

What is the exit? If the owner leaves or the tool stops earning its keep, how do you get the data out and what do you move to? A tool you can leave is a tool you can safely adopt. The team in the story had one, which is the only reason their version ends with “we went back to Linear” instead of something much worse.

Answer those and build the thing. The answers are often good. A four-hour monthly obligation for a tool your whole team prefers is a fine trade, and now you are making it deliberately.

Avoid the version where nobody asked, the tool works, and the bill arrives in instalments nobody attributed to it. That is how a team concludes it has gotten slower, when it has spent everything it had.

6. The version with no Linear to go back to

Everything above is the low-stakes version. An internal tracker is the safest place to learn this, because the exit is one subscription away and the blast radius is your own team’s patience.

The same logic runs through your actual product, at a size where none of that holds.

An AI-assisted build gets you to something that works, fast, and the demo will impress people. You also take ownership of every architectural decision made on the way there, including the ones nobody made on purpose. Those come due on the same schedule the internal tool’s did, in the same currency, except the bill lands while you have paying customers sitting on top of it. No vendor to fall back to, no export button, and no version of the sentence “we went back to Linear.”

That is the difference between the two halves of the story, and it is worth naming plainly. Both teams built something that worked. One of them could hand the puppy back.

Ownership rather than authorship is the useful lens well beyond internal trackers. It is the same question sitting under an inherited codebase, an outsourced build, a no-code stack that grew into a business system, and the MVP that quietly became your architecture. In each case the interesting question is not who wrote the code. Most of the time now, the honest answer is partly a model, and it does not tell you much. The question is who owns the consequences of that code continuing to exist.

It was never about whether AI can write the code. It writes the code. Ask instead who is going to own it on the Wednesday it breaks, and whether that person was ever asked.