When building becomes easy, you build too much. That's the main risk of the current period: accumulating dozens of quickly produced internal tools that no one maintains and no one understands six months later. The right question has never been "can I do it", but "who will look after it in two years".
We reported this morning that a third of organisations have given up buying software because they could build it instead. Here's how to decide without regretting it.
Question 1: is it specific to you?
This is the most discriminating criterion. A tool that fits your way of working, your fields, your business vocabulary, doesn't exist on the market — or exists in a generic version that will force you to adapt your processes to the software.
Build what is unique to your organisation. Buy what everyone does the same way: accounting, payroll, messaging.
Question 2: who answers for it if things go wrong?
Bought software comes with a contract, support and liability. An internal tool comes with you.
For anything touching regulatory obligations, health data, or decisions about people, this difference is decisive. We saw this regarding recruitment: some applications fall under demanding regimes, and compliance has to be demonstrated.
Question 3: does the value come from the code or from something else?
Many software products are not valuable because of their code but because of what comes with it: a database you don't have, a network of users, integrations maintained with fifty other systems, a certification.
These elements cannot be reproduced with a coding tool, however powerful. That's the logic behind Thomson Reuters: the corpus is the asset, not the software.
This is the question people skip and the one that costs the most. An internal tool has to be fixed when an API changes, updated when a vulnerability appears, documented for those who come later, and taken over when its author leaves. A useful rule of thumb: maintenance costs more over the lifetime than the initial build, and that gap widens when building becomes fast. If you can't name the person who will look after it in eighteen months, don't write that tool.
Question 5: what is the cost of changing your mind?
An internal tool can be modified whenever you want. Bought software has to be endured, until renewal.
But the reverse also exists: bought software can be abandoned by cancelling, while a poorly designed internal tool stays with you for a long time because no one dares touch it.
The real question is therefore reversibility in both directions, and it ties back to the principle we keep repeating: what matters is not making the right choice today, it's the ability to change it tomorrow.
The third way, often the best
The debate is rarely binary. The most robust configuration often consists of buying the base and building the thin layer: market software for what is standard, a lightweight internal tool for what is specific to you, connected through interfaces.
This also limits risk: if your internal layer becomes unmanageable, you throw it away without losing the foundation.
What to remember
Agentic tools have reduced the cost of building, not the cost of owning. These are two different things, and confusing them is the most common mistake right now.
The most honest test comes down to one sentence: imagine the person who is going to write this tool leaves the company in six months. If you can still answer "who takes over", build. Otherwise, buy, even if it's a less good fit.