Aller au contenu
Article 9 min read

Build or buy: the calculation almost nobody actually runs

Off-the-shelf always looks cheaper on day one. The five criteria that genuinely decide it, the three-year arithmetic no vendor shows you, and the trap of the 80 percent fit.

By Laurent Tulpan

The question arrives in the wrong order almost every time. Someone collects a licence quote and a development quote, puts them side by side, and picks. But those two documents do not propose to solve the same problem, so comparing their totals tells you nothing except which vendor prices lower.

Here is the calculation that actually decides it.

What each option really buys

Off-the-shelf software buys you other people’s decisions. Thousands of companies have already used it, the edge cases have surfaced, the roadmap exists, and someone else pays for the maintenance. That is a large amount of value for a monthly fee.

What it costs is that you adopt its process. A product encodes a way of working, tested across a market, and you have to move toward it for the thing to function. Configuration absorbs some of the gap. Past that point, every customization becomes a cost you re-pay at each upgrade.

Custom software buys you your own process, exactly. Including the edge cases nobody wrote down, and the rule three people know by heart. It imposes no reorganization.

What it costs is that nothing comes free: what you did not ask for does not exist. And someone has to keep it alive, which is an organizational commitment as much as a budget line.

The five criteria that decide

1. Is the way you work an advantage or an inheritance? The most important question and the least comfortable. Some of your specifics are why customers pick you; aligning them to a standard destroys the thing you were protecting. Others are simply accumulated habit that nobody has re-examined in a decade, and a product is a good excuse to clean them up. Nobody outside can settle this for you, but it has to be settled.

2. Is the scope structural or bounded? If the need touches accounting, purchasing and inventory at once, you are looking for a system of record, and building one from scratch would be reckless. If the need is one identifiable process with a start and an end, building is proportionate.

3. How many seats, over what horizon? Per-seat pricing is painless at five users and a real line item at forty over five years. Custom inverts the curve: expensive up front, roughly flat afterwards. Run both over three to five years including maintenance, not to pick the cheaper one but to know whether you are arguing about ten percent or about a factor of two.

4. Who keeps it alive? A product needs an internal owner who knows the configuration and a vendor who answers. Custom software needs someone able to change it, internal or not. Both create a dependency. They are just different dependencies, and it is better to choose which one you prefer than to discover it.

5. What is the actual deadline pressure? A product can be running in weeks. Custom takes longer, and the data migration takes longer still. If a problem is costing money every week, the duration of the project is part of its cost.

The three-year arithmetic no quote shows you

This is the total cost of ownership, and the reason to compute it yourself is that no vendor computes it for you. Four lines, and two of them are missing from most comparisons.

The subscription, extended honestly. Per seat, per month, times the seats you will have in three years rather than today, and with the price increase the vendor is contractually allowed to apply.

The configuration and integration work. Buying is not installing. Someone maps your data, connects the accounting system, trains the users. This line frequently exceeds the first year of licences and it is quoted separately, when it is quoted at all.

The upgrade tax on customizations. Every specific development inside a product has to be revalidated when the product moves. If your plan involves several, you have signed up for a recurring project, not a one-off.

The cost of the process you will abandon. The hardest to quantify and the most consequential. If adopting the product means your team stops doing the thing that made you faster than competitors, that is the real price, and it does not appear anywhere.

The trap of the 80 percent fit

This is where most of these decisions go wrong, and it is not for lack of diligence.

The product covers 80 percent. Everyone agrees it is a good fit. The remaining 20 percent gets handled with a few customizations, which seems reasonable at the time. Two years later, the upgrade has become a project, the customizations have their own bugs, and the vendor’s support politely declines to help with the parts you added.

The question to ask is not what proportion is covered but what kind of thing the gap is. If the missing 20 percent is invoicing formats and reporting layouts, buy and adapt. If it is the scheduling logic that lets you quote faster than anyone in your region, the product covers 80 percent of what matters least.

The configuration that works most often is neither pure: a product for the standard layer, because accounting is not your competitive advantage, and a dedicated tool for the process that differentiates you, with a documented interface between them so nothing is entered twice. That last clause is the one people skip, and it is the one that decides whether the arrangement holds.

The mirror-image trap

Building has its own version, and it is symmetrical.

A precise need is identified, a dedicated tool is built, it works. Then invoicing is added, because it is adjacent. Then payment tracking. Then a rudimentary ledger. Three years later you have rebuilt a product, worse, without ever deciding to.

The countermeasure is not refusing all evolution. It is naming the boundary at the start and testing every request against it: does this belong to the problem this tool solves, or to a different problem? A request that belongs to a different problem should prompt a conversation, not just an estimate.

How to decide without spending six months

Three steps, and the first is the one that gets skipped.

Write down two real processes, end to end. Not the features you expect: the actual sequence, including what happens when it goes wrong. This document is what reveals whether your business fits a standard, and it stays useful whichever way the decision goes. Our requirements template exists for exactly this.

Demo on your own cases, not theirs. Bring your two processes and your awkward edge cases to the vendor demo. An hour spent this way is worth three months of configuration discovered later.

Cost both options over five years. Licences, integration, maintenance, upgrades. Not to pick the cheaper one, but to know the size of the gap you are arguing about.

If those three steps need a technical read from someone with no stake in the conclusion, that is what a short paid assessment is for: if the recommendation is to buy the product, we get paid the same.

Further reading

Questions

Straight answers.

  • At what point does building become cheaper than subscribing?

    It turns on two variables: how many people need a seat, and how far the product sits from what you actually do. A subscription is paid monthly, per user, indefinitely, and it grows as you grow. Custom software costs more up front and then costs mostly its maintenance. Over three to five years with a team that is expanding, the arithmetic often favours building. On a standard need with a small team, buying wins, and it is not close.

  • The product covers 80 percent of what we need. Is that good enough?

    Look at the nature of the missing 20 percent before answering. If it is administrative housekeeping, buy the product and adapt. If it is the process that differentiates you commercially, then the product covers 80 percent of what matters least. The usual right answer is to buy for the standard layer and build for that 20 percent, connected by a documented interface, rather than paying for customizations inside the product that you will pay for again at every upgrade.

  • Isn't off-the-shelf safer because thousands of companies use it?

    On vendor longevity, often yes, and that is a legitimate argument. On fit, the logic inverts: a product used by thousands of companies encodes the process of the majority, not yours. If the way you work is part of why customers choose you, aligning it to a standard erases the advantage you were paying to protect. The question is not robustness, it is whether your specificity is worth anything.

  • How do we compare total cost of ownership fairly?

    Put both options on the same horizon, five years, and include the lines that quotes leave out: the per-seat subscription at the headcount you will have then rather than today, the configuration and integration work, the upgrade tax on every customization inside a product, and the cost of the process you would abandon. TCO is not the licence price plus the build price; it is everything that leaves your account because of the decision. Most comparisons stop at the first line.

  • What is the most common mistake in this decision?

    Comparing a licence quote with a build quote before deciding what kind of thing you need. The two proposals do not solve the same problem, so the numbers are not comparable. Write down two real end-to-end processes first, including what happens when they go wrong. That document tells you which category you are in, and it is useful afterwards whichever way you go.

Read next

More from the blog

Next step

Recognize the situation? Twenty minutes is enough.

Describe what is happening on your side. We will say plainly whether we can help, and if another route would serve you better, we will say that instead.

Start a conversation See the services