Why We Bought an Internal Tool

We ship nine of our own apps and use all of them every day. That is exactly why this is a note about the time we did not build one.

Building software used to be the expensive part. It is not any more. A capable developer with the current AI coding tools can put together in a couple of days the kind of internal tool that used to take a month. That shift is real, and it has quietly changed the temptation. When building is cheap, "we could just build that" becomes the answer to almost everything, especially in a studio where building things is the day job.

So the discipline that matters now is not knowing how to build. It is knowing when not to. And the clearest example we have is sitting in front of us all day: our issue tracker.

We could have built the tool

We run scheduled agents against our project tracker. One reads incoming issues, sorts them, tags them, and surfaces the ones a person should look at now. Another pulls the week's project data and writes a Monday-morning summary of what is blocked, what has slowed down, and what needs a decision. That part is genuinely useful, genuinely ours, and genuinely worth the effort.

The tracker underneath all of that is not ours. It is an off-the-shelf product we pay for. And every few months somebody points out, correctly, that we could build our own. We know exactly how an issue tracker works. We have firm opinions about the ones that exist. The time could be found, and with today's tools the first version would not take long.

We have not built it, and we are not going to. Here is the reasoning, because it is the same reasoning we give clients who are about to build something they should rent.

Development was not the main cost

An issue tracker is a solved problem. Thousands of teams need almost exactly the same thing, a company spends all day improving it, and the result is better than the version we would keep up in the gaps between client work. Building our own would not make our projects run any better. It would just move a working tool off someone else's maintenance budget and onto ours.

That last word is the one builders fixate on and buyers tend to skip. The cost of an internal tool is not the build. It is the years afterwards. Something you buy arrives with the updates, the security patches, the bug fixes, the new feature somebody asks for, and the person on call when it breaks at the wrong moment. Something you build arrives with all of that too, except now the someone is you, forever, for a tool that was never the point of the business.

AI has made the first day cheap. It has not made day four hundred cheap. The build-versus-buy sums changed; the maintenance sums did not. A tool you can stand up in an afternoon is still a tool you have to keep alive for as long as the team leans on it, and most of the real cost lives in that long tail nobody demos.

Buying has risks too. When you rent a tool you accept someone else's pricing, someone else's roadmap, and the small chance they change the rules or close the thing down. That is a genuine trade. You give up some control in exchange for never having to maintain it. For a problem that is common and well solved, it is almost always the right trade. For one that sits at the heart of how you work, it may not be, which is the whole point of choosing rather than defaulting.

Custom software must create a real advantage

None of this is an argument against building. We have built nine apps and we rely on every one. The point is that they pass a test the issue tracker fails.

We built a tool for managing several working copies of a codebase at once, because the way we move across many branches is specific to how we run projects and nothing off the shelf fit it cleanly. We built one that takes quick snapshots of a development database so you can roll back after a bad change, because the existing options were heavier than the job needed. We built Clio, a shared memory that the team's various AI tools all read from, because the whole value was keeping that material on our own machines rather than in someone else's database.

The pattern is consistent. We build when the workflow is genuinely ours, when we do it often enough for the saving to compound, and when what exists serves it badly. We buy when the problem is common, somebody already solves it well, and our version would just be a worse copy we now have to look after. The AI models we use every day fall on the buy side too. We pick the tool that fits the job and switch when the job changes, rather than trying to build the part of the stack that several enormous companies are already pouring billions into.

Cheap AI can distort the buy-or-build decision

If you are weighing up an internal tool, the decision usually comes down to two questions. Is this workflow genuinely particular to how you work, or is it a common problem dressed up as a special one? And are you ready to own the result for years, not just stand up the first version? Build when the answers are "ours" and "yes". Buy when they are "common" and "not really".

The trap, and it is a new one, is letting cheap-to-build fool you into thinking cheap-to-own. The fact that AI can produce a working tool in a day is one of the most persuasive reasons to build something, and one of the worst, because it hides the part that actually costs you. A demo is free. A dependency is for keeps.

We are, by trade, the people you would expect to tell you to build. That is precisely why it is worth hearing us say that some of the most useful calls we make are the ones where we don't. If you are looking at a workflow that has outgrown a spreadsheet and trying to work out whether it wants a custom tool or an off-the-shelf one, that is a good thing to settle before anyone writes a line of code. The next step is our Free 20-minute call. We will give you the same answer we would give ourselves.