Build or buy software: the decision grid

The question behind the question

"Should we build or buy?" is almost always asked with a budget in mind. Yet budget should rarely decide it, because both options are expensive in different ways and over different timeframes.

The useful question is simpler: does this process set you apart from your competitors? What sets you apart deserves custom tooling, because that is where your margin lives. What you share with everyone else should be bought, because someone has already done it better and cheaper than you would.

Six questions that are enough to decide

• Does a competitor do exactly the same? If yes, buy. Nobody ever won a customer through their way of issuing invoices.
• How many market tools have you tried? If the answer is zero, it is too early to build. If it is three and none fitted, you have a real signal.
• Will the need change? A process that shifts every six months is better steered with a tool whose keys you hold.
• How many people will use it? Licences are paid per head and grow with you; development is paid once and maintained.
• What happens if the vendor disappears or triples its prices? If that answer is frightening, the dependency is already a risk.
• Must your data stay with you? Some constraints settle the question without discussion.

Buying: what it really gives you

Off-the-shelf software is available immediately, tested by thousands of users, and its cost is predictable. The vendor absorbs legal changes, security fixes and new features without you having to think about it.

It is an excellent choice for everything common: accounting, payroll, email, electronic signature, leave management. Having those built means paying dearly to reinvent something already solved.

The limit appears when the tool imposes its way of working. There is one telltale sign: teams keep a spreadsheet on the side to compensate for what the tool does not do.

Building: what it really gives you

Custom software matches your way of working instead of constraining it. It carries your vocabulary, your rules, your exceptions, and it evolves when you do. You own it, which shelters you from a price rise or an acquisition.

It is the right choice when the process is your competitive advantage, when no market tool covers the need, or when the sum of licences exceeds the cost of development over time.

The limit is real too: software you have built must be maintained, hosted and documented. It is not a purchase, it is a commitment.

The five-year calculation

Comparing a subscription price with a development quote is misleading, because the two cover neither the same scope nor the same period.

On the buy side, count licences for the headcount you expect in five years, initial configuration, training, add-on modules and the exit cost if you change your mind. On the build side, count design, delivery, hosting, annual maintenance and enhancements.

This calculation often reverses intuition. A subscription at a few tens of euros per user becomes a considerable sum over five years with a growing team. Development that looks expensive up front amortises, and belongs to you.

The most frequent answer: both

In most companies we work with, the right architecture is neither all bought nor all built. Standard functions live in market tools, the core business lives in a dedicated platform, and the two exchange through an API.

That split takes a little thought up front and avoids the two classic regrets: having bent your trade to fit a tool, or having rebuilt an accounting system that already existed.