Building your own tool instead of renting one

For twenty years the answer was obvious: you do not write your own software, you buy a subscription. That calculation has changed, because the cost of building a custom tool has fallen by a factor few company owners have taken in. Here is how to decide, without swinging to the opposite extreme.

What assisted development has really changed

You hear about development assisted by generative artificial intelligence, sometimes under the name vibe coding. Behind the phrase, the reality is easy to describe.

An experienced developer describes in plain language what they want, the assistant writes the code, the developer reads it, corrects it, tests it and puts it into service. What used to take weeks takes days. A data entry screen, a data processing pipeline, a small line-of-business tool with its screens and its validation rules: all things whose manufacture ran into tens of thousands of euros and now runs into thousands.

Note carefully what has not changed. You still need somebody who can read code, recognise a mistake, set an architecture and deploy to production. The assistant speeds up a practitioner, it does not replace the skill. A manager who describes their need to an assistant with nobody to review the result gets a convincing demonstration, then discovers three months later that it stands up neither to the edge cases nor to real load.

But the boundary has moved a long way. Needs that did not justify bespoke development, and for which people therefore put up with ill-fitting off-the-shelf software, now justify it.

Three arguments for building

The cost of building has collapsed

Compare over three years. A subscription at thirty euros per user per month, for twenty users, comes to more than twenty thousand euros over the period, and that figure rises with every price revision and every new hire. An internal tool built for one precise need sits, for a bounded function, in a comparable order of magnitude, with no perpetual rent afterwards. The line-by-line version of that comparison is in our guide on what generative AI actually costs.

The tool fits the work

This is the decisive argument, far more than price.

Off-the-shelf software imposes its vocabulary, its divisions and its steps. Your teams spend part of their time translating their trade into the publisher’s model, maintaining parallel spreadsheets for whatever the tool cannot do, and working around mandatory fields that correspond to nothing in your business. That cost appears on no invoice and it is frequently larger than the subscription.

At a twenty-person consultancy, the analysts prepare location studies, work that follows a method peculiar to the firm and that no commercial software knows anything about. We built them a tool for designing those studies, which they operate directly. It does one thing, it does it in their own terms, and it demands no translation from them.

That last point has a consequence people underestimate until they have lived it. A tool that speaks the team’s language needs almost no change management. There is nothing to roll out, nobody to convince, no resistance to overcome. Users adopt it because it saves them time from the first use, not because management told them to.

The data stays with you

An internal tool runs in your own infrastructure or on hosting you choose. No customer database goes off to a third-party publisher, the hosting region question is settled by a single decision, and the matter of cascading subprocessors disappears. For sensitive data, that argument sometimes outweighs the other two.

The other side, without flattery

Now for why the received wisdom of the last twenty years said buy rather than build. It had good reasons, and they have not all gone away.

An internal tool almost always dies the same way. Nobody maintains it, because the person who made it has left or moved on to other priorities. It has no tests, so the smallest change breaks something and nobody sees it. It has no monitoring, so it fails on a Thursday and gets noticed the following week. And it rests on a single expert, which makes it a disguised dependency far riskier than a subscription.

There is a fifth symptom, more insidious: the tool that grows. Designed for one task, it gets a second function, then a third, until it becomes a full management system that nobody ever architected as one.

These risks are real. They are also avoidable, provided you deal with them on day one rather than thinking about them later.

How an internal tool survives

Four requirements, and they are not negotiable if the tool is going to matter to your operations.

• Automated tests on the core business rules, run on every change.
• Monitoring that alerts a named person when a job fails.
• Short documentation aimed at operations: how it runs, where it runs, what to do when it breaks.
• At least two people able to intervene, one of whom did not build it.

Monitoring deserves a paragraph of its own, because it is the item most often sacrificed. At the same client, processing pipelines import and check large public reference datasets, such as the national company register, points-of-interest data and open mapping data, then load them into the data warehouse and the application databases. Those pipelines are checked every month, with an alert raised on any anomaly.

There is nothing impressive about that arrangement. It cost a fraction of the build time. But it is what allows anyone to say that those pipelines work, instead of hoping they do. A monitored internal tool is an asset. An unmonitored internal tool is a debt that does not know it.

The single-expert problem is settled by how the work is done. A tool built in your own repositories, with your team involved in making it and an explicit handover phase, does not depend on its author. That is exactly the purpose of the third stage of our method: installing the solution in your hands and progressively stepping back from it.

When buying is still clearly right

It would be absurd to conclude that everything should be built. In several situations the market subscription remains the right decision, and we say so to clients.

When the function is standardised and governed by external rules you do not control. Payroll, accounting, electronic invoicing, statutory declarations: these areas change at the pace of regulation, and a specialist publisher absorbs those changes for you. Rebuilding them would be a mistake.

When the market software is already a standard in your ecosystem, your partners and customers use it, and interoperability is worth more than the fit to your way of working. That is often the case for a customer relationship management tool or an office suite.

When the need is unstable and you do not yet know what you want. Start with an off-the-shelf tool, learn from it what you actually need, and build later if the gap becomes expensive.

And when the function is vital but you have no intention of funding a line of maintenance for it. An internal tool with no maintainer is more dangerous than an ill-fitting subscription.

So the right question is not whether to build or buy. It is where your specificity lies. Buy what everybody does the same way. Build what makes you different, and what no publisher will ever model properly because their market is elsewhere.

If you currently keep parallel spreadsheets to make up for what your software cannot do, you have probably already identified the right candidate. A diagnostic on that area will tell you what it costs to build and what it saves you.