Build vs Buy Software: The Five-Year Cost Maths

Caixa Mágica Team · 28 October 2026

The build vs buy software decision usually gets made with two numbers that are not comparable: a development proposal with a total, and a subscription with a monthly per-seat price. One looks enormous, the other looks trivial.

An honest build vs buy software comparison needs both lines across the same period, with everything each one drags behind it. Custom software has a high entry cost and a flat curve. A subscription has a low entry cost and a curve that rises with your headcount. The question is not which is cheaper. It is which year the two lines cross, and whether your decision horizon reaches that far.

At a glance

80% Coverage of your workflow by an existing product, above which buying is usually right
2–3× What total cost of ownership runs against the sticker subscription price
€30k–100k Where most small and mid-sized custom builds land
15–20% Of build cost, per year, to maintain software you own

Buy when an existing product covers roughly 80 per cent of the workflow. Build when that workflow is your competitive advantage, or when no product fits.

Build vs buy software: what does each option cost over five years?

The usual build vs buy software mistake is comparing the entry price. Off-the-shelf products have a low entry cost, real and understated setup costs, integrations often sold separately per connector, and a recurring cost that grows with seats, volume and modules. Custom software has a high entry cost, integrations that add 20 to 30 per cent to the initial build, hosting at €200 to €1,500 a month, and annual maintenance at 15 to 20 per cent of build cost.

The line that changes the arithmetic is the recurring one. A per-seat subscription grows when the company grows, which is exactly when the system is producing most value. Maintenance on software you own is a percentage of build cost and does not track business growth. The line that surprises most is setup: market references point to total cost of ownership running two to three times the sticker subscription once implementation, integrations, training and internal administration are counted. The advertised price is the smallest part of the bill.

Option	Cost curve	What it involves
Buy	Low entry, rising curve	Recurring cost grows with the company. Control is low, price increases are outside your hands, and if you stop paying, access ends. Fits common, regulated processes.
Build	High entry, flat curve	15 to 20 per cent a year in maintenance, plus hosting. Full control, and if you stop paying a supplier you still have the system. Fits processes that differentiate.
Hybrid	A product core, built edges	Subscription plus maintenance. A product handles the common core and compliance; you build integrations and the interfaces that differentiate.

Before deciding, ask for two things: the five-year subscription cost at the seat count you expect in year five rather than today, and the exit cost, meaning what it takes to get your data out, in what format, and how long it takes. Suppliers who will not answer the second question in writing are answering the first.

When is buying the right decision?

When the process is not yours and does not need to be. Whole categories exist where building is a waste of capital: accounting, payroll, email, video conferencing, document signing, ticket management. These processes look the same everywhere, are uniformly regulated, and have mature products with decades of investment behind them.

The practical test is coverage. If an existing product covers roughly 80 per cent of the workflow, buy. The remaining 20 per cent gets solved with process, with a small custom layer around the edges, or by accepting that one part stays less elegant. Three signals confirm it: the process is regulated and identical for everyone, so compliance belongs to the vendor; you need this working in weeks, and a configurable product is in use while a build is still in discovery; and the process does not differentiate the business, so there is no return on being different.

When does building pay off?

When the workflow is the reason customers choose the company, or when no product fits.

The process is the competitive advantage. Adopting the product competitors also use erases the distinction. You become identical to everyone else, except now you pay monthly for it.

The product forces the business to change. There is a large difference between adapting a process to good practice and adapting a business to what the software can do. The second carries a real cost that never appears in the proposal.

Licensing grows faster than value. Per-seat or per-volume models can turn growth into cost. Project the subscription against your expected growth scenario, not against today.

Compliance requirements do not fit. Where the data sits, who has access, what evidence the system produces in an audit, how long it is retained. International products answer these questions in the way that suits most of their customers. If your answer differs, the gap may have no solution.

Between building and buying? Send us the process and the products you are evaluating.

Talk to our team →

Is there a third option?

Yes, and in practice it is the most common: buy the core and build around it. The usual pattern is adopting a product for the core of the process, which handles compliance and maintenance, then building the layer that differentiates, meaning integrations with internal systems, interfaces for the people using it every day, and automations the product does not anticipate.

This requires one non-negotiable condition, checked before signing: the product needs a documented API and the ability to export your data. Without that, the custom layer rests on something that can change without notice, and the strategy stops being hybrid and becomes dependency.

What did AI change about build vs buy software?

Less than vendors suggest, and more than it appears. On the build side, assistance tools speed up part of the work, with 54 per cent of developers already using them in their regular workflow, which reduces cost on certain kinds of repetitive code. On the buy side, nearly every product has added AI features and nearly every one charges for them separately, and AI integration can add up to 30 per cent to the cost of a development project, which suggests it is not free on that side either.

What has not changed is the structure of the decision. Building is still expensive to start and cheap to keep. Buying is still cheap to start and grows. AI moves both curves slightly and does not change the question of which one suits your case.

How do you decide build vs buy software without a spreadsheet?

Four questions settle most build vs buy software decisions, asked in order. The first one that answers clearly decides.

1
Is this process why customers choose us? If yes, build. The cost discussion is secondary to erasing a competitive difference.
2
Does a product cover roughly 80 per cent of this? If yes, buy and handle the rest with process. If it covers 50 per cent, it is not the right tool, it is a similar tool.
3
Is the year-five subscription, at expected growth, still acceptable? If the number is alarming, run the full comparison against build plus maintenance. You may already be past the crossover.
4
If the vendor disappears or triples the price, what happens? If the answer is "we have a serious problem", that is risk to price, not a footnote.

What should a build vs buy software decision record?

Write the decision down, even when it feels obvious. In three years someone will ask why the company built or bought. The people who decided may no longer be there to answer.

A single page is enough. It should name the process being supported, the products that were evaluated and how much of the workflow each one covered. It should show the five-year cost of both options, the exit cost of the product that was chosen or rejected and the assumptions behind the growth figures. Keep the vendor quotes attached, with their dates.

It should also name an owner and a review date. A build vs buy software decision is right for the conditions that existed when it was made. When the user base doubles, a product releases the missing feature or the vendor changes its pricing, the review date is when someone checks whether the answer still holds.

The record takes an hour to write. Without it, the next team repeats the evaluation from scratch or, worse, assumes the original reasoning still applies when nobody can say what it was.

Frequently asked questions

Cost over time

Is it cheaper to buy software or build it custom?

In the short term, buying. Off-the-shelf products have a low entry cost, while public data places most small and mid-sized development projects between €30,000 and €100,000. Over five years the answer depends on growth: subscriptions scale with seats and volume, while maintenance on software you own runs at 15 to 20 per cent of build cost per year.

What is the total cost of ownership of an off-the-shelf product?

It is the subscription plus everything else: implementation, configuration, data migration, integrations sold separately, training and internal administration. Market references point to a total of two to three times the sticker subscription, which makes the advertised price the smallest part of the bill.

How much does custom software cost to maintain after it is built?

Public references converge on 15 to 20 per cent of build cost per year, with hosting and infrastructure adding €200 to €1,500 a month. On a €100,000 build, that is €15,000 to €20,000 a year before any new feature.

Making the call

What is the 80 per cent rule?

It is the simplest test for deciding: if an existing product covers roughly 80 per cent of the workflow, buying is usually right, with the remaining 20 per cent handled by process or a small custom layer. Below that level you are adapting the business to the software rather than the other way round.

When is custom software worth building?

When the workflow is the business's competitive advantage, when no existing product covers the essentials, when the licensing model grows faster than the value generated, or when compliance and data residency requirements do not fit what the product offers.

Can I combine both approaches?

Yes, and it is the most common pattern: a product for the core of the process and custom development for the layer that differentiates, including integrations and specific interfaces. The condition is that the product has a documented API and allows data export. Without that, the custom layer sits on unstable ground.

Caixa Mágica Team

Caixa Mágica Software is a Portuguese software company with 20+ years of experience delivering custom software, AI solutions and nearshore development teams for European businesses.

Software Development · Caixa Mágica Software

Bring us the decision before you have made it

We build custom software and tell clients when it is not worth it. If you are between building and buying, send us the process and the products you are evaluating. You get where the gaps are, what building would cost, and the scenarios in which buying wins.

Custom software development Start a conversation