Sooner or later a growing business outgrows its systems. Orders get re-keyed, stock figures disagree and month-end drags on. The fix usually comes down to one question: build something, buy something, or extend what you already have? This guide walks through how to decide. It uses one example throughout: a wholesale distributor with 180 staff whose systems date from 2011.

Start with the problem

Before comparing solutions, write down the problem in the words of the people who live with it, with numbers where you can get them: "14 hours a week re-keying orders from email", "web-shop stock up to a day out of date", "month-end takes nine days". Then note which of these problems are how you compete and which are simply work that has to be done.

That distinction drives most of the decision. Standard processes, such as accounting, payroll and email, are rarely worth building. Processes that set you apart, such as how you quote, price or serve customers, sometimes are.

The three options

• Build a custom application around your process. It fits exactly and you own it, but you carry the delivery risk and the upkeep.
• Buy a product and adapt your process to it. It's proven and supported, but you pay per user, adapt to its way of working and depend on its roadmap.
• Extend what you have with integrations, automation and a thin custom layer where it matters. It's often the fastest and cheapest route, but it has limits if the core system is near the end of its life.

Most real answers are a mix: buy the standard parts, and build or extend where you're different.

Total cost of ownership

Compare options over three to five years, not on the first invoice. For each one, add up:

• upfront costs: licences or build, setup, integration and data migration;
• running costs: subscriptions, hosting, support and the people who look after it;
• change costs: training, process changes, and the productivity dip while people adjust;
• exit costs: what it would take to move away later.

For the distributor, the three-year totals came out at about €1.1M to build a custom order platform, €780k to buy a new ERP suite and €420k to extend the current ERP with integrations and an order portal. The illustration at the top scores the three side by side.

The costs people forget

The line items that sink business cases are rarely the licences:

• integration: every system that needs to exchange data with the new one;
• data migration: cleaning and moving years of records, which is almost always messier than expected;
• process change: the product's way of working replacing yours, and the training that goes with it;
• sprawl: tools bought team by team that overlap. Zylo's 2026 SaaS Management Index, based on its customers' data, puts the average company at 305 SaaS applications and $55.7M a year of SaaS spend. Those customers skew large, but the pattern holds at smaller scale.

Lock-in and exit

Every option creates some lock-in. Ask each vendor, and yourselves, three questions before you sign:

• Can we export all our data, in a usable format, at any time?
• What happens to price and support at renewal, and when the product changes direction?
• If we built it, could another team pick it up from the code and the documentation?

Risk and time to value

Big projects carry big risk. In a study of more than 5,400 IT projects by the University of Oxford and McKinsey, large projects (initial budgets above $15M) ran 45% over budget and 7% over time on average, while delivering 56% less value than predicted. Bent Flyvbjerg and Alexander Budzier, studying 1,471 IT projects, found that "one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%."

The lesson isn't to avoid building. It's to avoid betting everything on one big delivery. Whichever option you choose, phase it so the first phase delivers something useful within months, and set points where you can stop or change course.

A decision matrix

Score each option against the criteria that matter to you, weighted, and write down the reasoning. The written reasoning matters more than the score: it's what lets people challenge the decision now and understand it later.

A short checklist

• The problems written down in the words of the people doing the work, with numbers.
• Standard processes separated from the ones that set you apart.
• All three options costed over three to five years, including the hidden costs.
• Data export and exit terms checked before signing anything.
• A phased plan, with something useful in the first months.
• Points where you can stop or change course.
• The reasoning written down, not only the score.

Common questions

Is building always more expensive?

Upfront, usually. Over five years, not always: per-user subscriptions add up, and a custom tool that removes manual work can pay for itself. That's why the comparison has to cover the whole life of the system.

What if the core system is near the end of its life?

Then extending it buys time, not a future. Use the extension phase to reduce risk, by cleaning the data and wrapping the old system behind clean interfaces, while you plan the replacement.

Who should make the decision?

The people who own the outcome, with the people who do the work involved from the start. An outside view helps most with the costs, the options and the questions that are awkward to ask internally.

---

Sources, as of October 2026: Delivering large-scale IT projects on time, on budget, and on value (McKinsey and the University of Oxford) (opens in a new tab), Why your IT project may be riskier than you think (Harvard Business Review) (opens in a new tab), Zylo 2026 SaaS Management Index (opens in a new tab).