Build vs buy software: the expensive decision is where the two meet
Almost every organisation past a certain size already runs custom software and off the shelf products side by side. The choice that costs real money is not which one to pick. It is where the line between them falls, and who owns it.
The short version
- Build versus buy is written as a choice of side. Any organisation running more than a handful of systems already has both, so the live decision is where the boundary between them sits.
- Every page that ranks for this question is published by someone who sells one of the answers. Read the recommendation, then check what the publisher sells. The two match almost every time.
- The boundary itself is the part nobody prices. It has a build cost, a running cost, an on-call owner, and a bill that arrives every time a vendor ships a release you did not schedule.
- The statistic most often used to argue against buying, that the large majority of features in off the shelf products go unused, traces to a conference talk about four in-house applications. It was never a finding about commercial software.
- Building carries real tail risk. Across more than five thousand large IT projects, the average ran 45 percent over budget, and the wider research shows a long tail rather than a predictable middle.
- Before choosing either path, settle what it would cost to reverse the decision in three years. If neither option has an exit you can describe in a sentence, the analysis is not finished.
You are not choosing between them. You already run both.
Finance closes the month in a package somebody bought years ago. Operations runs on a spreadsheet that quietly became load bearing. There is a portal somewhere that a contractor built, which nobody wants to touch. Then a new requirement arrives, and with it the question: do we build this or buy it?
The question arrives as though the answer were a clean slate. It is not. It arrives into an estate that already contains both kinds of software, already has data moving between them, and already has someone who gets called when that movement stops. Whatever you choose becomes the next element in that estate, and it will be judged on how well it sits alongside everything already there.
This matters because the binary framing quietly changes the subject. It invites a comparison of two columns, features against price, and a decision about which column wins. That comparison is not wrong, exactly, but it is answering a smaller question than the one in front of you. The larger question is what your estate should look like in three years, and which parts of it you intend to own.
We build custom software for a living, so treat what follows accordingly. The reason we are willing to argue against building, repeatedly and in specifics below, is that the projects that go badly for us are the ones where a client built something they should have bought. Those projects are unhappy long before they are unprofitable.
Custom software vs off the shelf, and the third path most estates take
Three options are on the table, and the third is the one most organisations end up on whether or not they chose it deliberately. Framed as off the shelf software vs custom software the choice looks binary, which is part of why the third option is so often reached by accident rather than on purpose.
Buying off the shelf
You license a product built for many organisations at once: a commercial off the shelf package, or more commonly now a subscription product. Somebody else carries the cost of building it, keeping it secure, and keeping it current. You configure it within the range the vendor decided to expose, and you accept the shape of the workflows it assumes.
The trade is genuine and it is usually good. You are buying a product that has already survived contact with thousands of organisations, including their edge cases and their auditors. That is a great deal of hardening you do not have to pay for.
Building custom software
You commission a system shaped to how your organisation actually works. Nothing has to be worked around, because nothing was designed for somebody else. You own the code, the data model, and the roadmap, and you carry the cost of all three for as long as the system lives.
The case for it is strongest where the process itself is the advantage. If the way you route work, price a job, or schedule a plant is a real differentiator, encoding it in a product designed around somebody else’s assumptions dilutes the thing that makes you competitive.
Buying and extending
You buy the platform and build the part that is yours: an integration layer, a workflow the product does not model, a customer facing surface on top of a bought back end. Most estates arrive here eventually. It is the pragmatic answer, and it is also where the boundary questions in this article bite hardest, because extending is the option that puts your code and a vendor’s product in the same critical path.
Notice what these three have in common. Every one of them ends with a boundary somewhere: between the bought thing and the built thing, between your data model and theirs. The choice is not whether to have a boundary. It is where to put it and how much of it you are willing to own.
The boundary is where the money goes
Read enough comparisons of custom software against off the shelf software and a pattern shows up. Both columns are costed in detail. Licence fees, implementation, developer time, maintenance, training. The space between the columns is costed at nothing, because in a two column comparison it does not appear at all.
In practice that space is a system in its own right. Data has to move between the bought thing and the built thing. Something has to decide which side is authoritative when both hold a version of the same customer. Something has to handle the case where the vendor’s product accepts a record that yours rejects. Someone has to be reachable when that fails on a Sunday.
None of that is exotic. It is ordinary integration work, and it is well understood by the people who do it. The problem is that it is almost never in the business case, so it is funded out of contingency, delivered under time pressure, and owned by whoever happened to build it. It then quietly becomes one of the most critical components in the estate and one of the least documented.
Why the boundary costs more than the estimate
Three things drive it, and none of them show up in a feature comparison.
The first is that a boundary has a running cost, not just a build cost. An integration is not a deliverable that completes. It is a small piece of production software with a monitoring requirement, a failure mode, an alerting policy, and a person who owns it. Organisations routinely budget the build and forget that the run is permanent.
The second is that you do not control both ends. The vendor on the other side of the boundary ships when it suits their roadmap. A field changes meaning, an endpoint is deprecated, an authentication method is retired with two quarters of notice. Each of those is a small piece of unplanned work landing on a team who were doing something else. You did not choose the timing, and you cannot decline it.
The third is that the boundary is where accountability gets fuzzy. When the bought product is slow, the vendor points at your integration. When your integration is slow, your team points at the vendor’s rate limits. Both can be right at once. Somebody has to own the whole path end to end, and if nobody was appointed at the start, that role is filled by whoever is most senior in the incident channel.
This is why the decision is better framed as an architecture question than a procurement one. Procurement asks which product wins. Architecture asks where the seams go, who owns each one, and what happens on the day a seam tears. The second question is answerable in advance, and answering it changes which product you should buy.
One boundary problem is large enough to have its own treatment: what to do when two systems hold the same record and disagree about it. We wrote that up separately in the context of running an old system and a new one side by side, and the rules there transfer directly. Decide the divergence policy before the systems are live, not during the first incident.
Seven questions about the boundary, before you choose a side
Answer these before you shortlist products, not after. They are quick to ask and they change the shortlist, because some products answer them badly and the answer is not in the feature matrix.
Which side owns the data model for each shared entity
Pick one system as authoritative for customers, one for products, one for orders, and write it down. Two systems that both believe they own the customer record will diverge, and the reconciliation work is permanent rather than one off.
What the integration costs to run, not to build
Ask for the monitoring, the alerting, the expected failure modes, and the person who is on call. A boundary with no named owner has an owner anyway: it is whoever answers the incident, and they will be improvising.
Who absorbs a breaking change when the vendor ships
Vendors deprecate endpoints and change field semantics on their own schedule. Establish the notice period you are contractually given, and who does the work when it arrives. This is unplanned effort you have agreed to accept, so it belongs in the plan.
What you owe the vendor once you extend their product
Extending couples you to their roadmap. Ask what happens to your extension when they rebuild the module it hangs off, whether your customisations survive a major version, and whether support is void where your code touches theirs.
How your data leaves, in what format, on what notice
Export rights are usually in the contract; useful exports frequently are not. A dump you cannot reconstruct relationships from is not portability. Ask to see a real export from a real tenant before signing, not a schema description.
Which team is accountable for the path end to end
Not each component: the whole path, from the user action to the record landing. Name that team while everyone is still friendly. Boundaries fail in the space between two teams who each believe their part is working.
What it would take to reverse this in three years
Describe the exit in a sentence for both directions, replacing the bought product and retiring the built one. If either sentence cannot be written, you are not choosing between two options. You are choosing one and closing the other.
A vendor who answers all seven precisely is telling you something about how they operate. So is one who cannot answer the fifth.
What the evidence actually supports
There is real research on this decision, and it says less than the confident numbers in circulation suggest. What it does support is worth knowing, because it points at risk rather than at a preference.
The strongest evidence concerns the build side, and specifically its distribution of outcomes. McKinsey, with the BT Centre for Major Programme Management at the University of Oxford, studied more than five thousand large IT projects and found they ran on average 45 percent over budget and delivered 56 percent less value than predicted, with 17 percent going badly enough to threaten the organisation itself. Note the definition before you apply it: their threshold for a large project is well above what most mid-size organisations ever commission, so this is evidence about big programmes, not about every build.
The shape of that risk matters more than its average. Peer reviewed work on IT project overruns across 4,677 projects found the distribution has a long tail rather than a predictable middle, meaning most projects land near their estimate and a minority miss by extraordinary margins. The practical reading for a build decision is that the question is not what the average build costs. It is what would put your build in the tail, and the honest answers are familiar: unclear scope, a data migration nobody surveyed, and sheer size. Those are the same three that dominate ERP budget overruns, which is the most heavily studied version of this problem.
On the buying side the useful evidence is about what happens after the signature rather than before it. The SaaS management vendor Zylo publishes an annual index reporting that organisations use only around half the licences they pay for, and that a large majority of IT leaders saw costs they had not anticipated after signing. Their figures are worth reading and their interest is worth stating: Zylo sells software that finds and reclaims unused licences, so a finding that licences go unused is a finding that supports their product. That does not make it wrong. It does mean it should not be the only source you consult.
Put together, the evidence supports something narrower than either side would like. Building at scale carries a genuine tail risk that buying does not. Buying carries a drift risk that building does not, where cost accumulates quietly through licences, seats, and add-ons that nobody revisits. Neither finding tells you which to choose for a particular system, and any article that uses them to do so is overreaching.
The number this argument is usually made with does not survive checking
One statistic appears more than any other when custom software is compared against off the shelf software: that the overwhelming majority of features in bought products, commonly given as somewhere between 85 and 90 percent, go completely unused. It is a persuasive number. If you are paying for a product and using a tenth of it, the case for building only what you need writes itself.
We went looking for the source. In one prominent article the figure appears with no source at all. In another it is credited to a well known startup author. Neither attribution holds.
The trail leads to a keynote given by Jim Johnson, then chairman of the Standish Group, at the XP 2002 conference. The figures he presented were that 45 percent of features were never used and 19 percent rarely used, which is where the frequently quoted 64 percent comes from. The 85 to 90 percent version in circulation is an inflation of an already specific claim.
The more serious problem is the sample. Mike Cohn traced the study behind that keynote and reported that it covered four internal applications, built in house at four companies. No commercial products were examined. His conclusion is blunt: anyone citing the figure to imply that products generally contain that proportion of unused features should, in his words, stop.
Sit with what that means. A finding about four bespoke in-house applications is routinely used as the central argument for commissioning bespoke in-house applications. If anything, read at face value, it is evidence about the risk of building features nobody asked for, which is a risk that belongs to the build side of this decision rather than the buy side.
None of this means bought products are efficiently used. Zylo’s licence data suggests they often are not. It means the specific number doing the heaviest lifting in this debate is not measuring what it is being asked to measure, and a decision of this size deserves better support than that.
What both sides underestimate
Total cost of ownership is where these comparisons usually end, and where they are usually thinnest. Each side has a characteristic blind spot, and they are not symmetrical.
What buyers underestimate
Configuration is work, and at enterprise scale it is often a project in its own right. So is the internal administration a serious product requires once it is live: someone owns permissions, someone owns the workflow changes, someone fields the questions. That role rarely appears in the business case and rarely disappears afterwards.
Then there is drift. Seats get added faster than they get removed. A module that was optional becomes necessary. A renewal arrives with an uplift, and by then the product is embedded deeply enough that the negotiation is not really a negotiation. None of these are hidden exactly. They are just spread across enough small events that nobody experiences them as a decision.
What builders underestimate
The build is the visible part and it is not the expensive part. What follows it is: security patching, dependency upgrades, browser and platform changes, compliance updates when a regulation moves, and the slow accumulation of small changes that keep a system matching the business it serves.
There is also a staffing question that is easy to defer and expensive to answer late. A custom system needs people who understand it, available for as long as it runs. That is a hiring commitment, a retention commitment, and a documentation commitment, which is why some organisations answer it with a team that stays with the product instead of with a hiring round. Organisations that build without deciding who maintains it usually find out during a resignation.
One asymmetry is worth naming because it distorts the comparison in a specific direction. Bought software produces a visible line item that finance reviews annually. Built software distributes its cost across salaries, cloud bills, and opportunity cost, none of which are labelled with the system’s name. The bought option therefore looks more expensive than it is relative to the built option, purely because it is easier to see.
What it costs to change your mind
Almost nothing written about this decision discusses reversing it, which is strange, because reversal is common. Products get acquired and repriced. A build outlives the team that made it. A process that was a differentiator becomes a commodity and a product now does it better than your code does.
The cost of reversing is not symmetrical, and knowing which direction you are making harder is part of choosing well.
Replacing a bought product is usually gated by data and by habit. The data has to come out in a form that means something, which returns you to the export question, and every integration built against that product has to be rebuilt against its replacement. The deeper the extension work went, the more of it is specific to a vendor you are leaving.
Retiring a built system is gated by knowledge. The rules encoded in it are frequently the only written record of how the business actually operates, and the people who know why a particular condition exists may have left. Migration then becomes an archaeology exercise before it becomes an engineering one, and the archaeology is the part that overruns.
There is a practical consequence for how you write contracts and code today. On the buying side, the exit terms matter more than the feature list, because features converge and exit terms do not. On the building side, documentation and a clean data model are not hygiene, they are the mechanism by which the decision stays reversible. Both cost little while the decision is still open, and a great deal once it has been made.
When each path is the right one
With the boundary questions settled, the choice itself gets simpler. These are the conditions under which each path tends to be right, stated as plainly as we can.
Buy when the function is genuinely common to your industry, when your process has no advantage encoded in it, when compliance or security expectations are heavy and a vendor already carries them, or when the thing you are short of is time rather than budget. Accounting, payroll, email, helpdesk and most of CRM sit here for almost everyone.
Build when the process is the differentiator, when the integration density is high enough that you would be writing most of the logic anyway, when a regulator expects something no product models, or when the workarounds your team has accumulated are themselves now the cost. If people have built spreadsheets to survive the product, the product is not fitting.
Buy and extend when a product covers the bulk of the requirement and the remainder is genuinely yours, and when the vendor exposes a real extension surface rather than a marketing one. Verify that surface before you commit, because this path fails quietly when the extension points turn out to be shallower than the sales conversation implied.
| Question | Buy | Buy and extend | Build |
|---|---|---|---|
| Who owns the data model | The vendor. You work within it. | Shared, and the split has to be written down. | You, entirely. |
| Who sets the release schedule | The vendor. You receive changes. | The vendor for the base, you for the extension. | You. |
| What a vendor release can break | Configuration and workflow assumptions. | Your extension, at a time you did not pick. | Nothing. Your dependencies still move. |
| Where cost is visible | A renewal line finance reviews annually. | Split across a renewal and a team. | Spread across salaries and cloud bills. |
| How the boundary fails | Integrations to your other systems. | The extension seam, which is the busiest one. | Integrations to everything you bought. |
| What blocks reversal | Data export quality and rebuilt integrations. | Extension work specific to a vendor you are leaving. | Undocumented business rules and staff turnover. |
| Fails most often because | The process never fitted and workarounds accumulated. | The extension surface was shallower than it looked. | Scope, migration, or nobody owning it after launch. |
If a decision looks finely balanced across that table, it usually means the requirement has not been split finely enough. Very few requirements are a single thing. Most are a commodity core with a genuinely distinctive edge, and the useful move is to draw the boundary between those two parts rather than to award the whole requirement to one column.
Where this leaves a decision you have to make this quarter
Split the requirement before you compare anything. Name the part that is common to your industry and the part that is yours. If the second part is small, buy, and spend the saved effort on the boundary. If it is large and it is genuinely where you compete, build that part and buy around it.
Then price the boundary explicitly, as a line with an owner rather than as contingency. Ask the seven questions above of every vendor on the shortlist, and treat evasiveness on the export question as the answer it is.
Finally, write down what reversal looks like in both directions while the decision is still open. It takes an hour, it costs nothing to do, and it is the single thing most often missing when we are called into an estate that has stopped fitting the business it serves.
Questions buyers ask about build versus buy
When should you buy software instead of building it?
Buy when the function is common to your industry and your way of doing it carries no advantage. Accounting, payroll, helpdesk and most customer relationship management fall here for almost every organisation, because the process is standard and a vendor has already absorbed the compliance and security expectations that come with it.
The exception worth watching for is when your team has quietly built a layer of spreadsheets and manual steps to make a bought product workable. At that point you are already paying for custom software, just without the benefits of having designed it.
What are the pros and cons of build vs buy software?
Buying gives you speed, a product hardened by many other organisations, and a predictable line item, at the cost of fitting your process to somebody else’s assumptions and accepting their roadmap. Building gives you exact fit, ownership of the data model and control of the schedule, at the cost of carrying maintenance, staffing and a genuine risk of overrun for as long as the system lives.
The list of pros and cons is not usually what decides it, because both lists are well known and roughly balanced. What decides it is the part missing from most versions of the list: who owns the integration boundary between the new system and everything you already run, and what that ownership costs every year.
How do you compare total cost of ownership when building versus buying software?
Compare over the same multi-year period, and add the categories each side habitually omits. For buying, that means configuration effort, internal administration, seat growth, renewal uplifts and the cost of leaving. For building, it means maintenance, dependency and security upgrades, documentation, and the staffing commitment required to keep people who understand the system.
Include the boundary as its own line on both sides, with a build cost and a running cost. Also correct for visibility: bought software appears as one reviewable invoice while built software hides inside salaries and cloud bills, which makes buying look more expensive than it is in a naive comparison.
What business problems are best solved by custom software rather than off-the-shelf?
Problems where the process itself is the advantage, and problems where no product models what a regulator or a contract requires of you. Routing, scheduling, pricing and fulfilment logic in operationally distinctive businesses are the common cases, along with anything that has to reconcile several systems that were never designed to agree.
A reliable practical signal is workaround density. When people maintain spreadsheets alongside a product, re-key data between systems, or keep private notes to remember what the software cannot express, the product has stopped fitting and the workarounds have become an unfunded custom system.
What should a build vs buy software licensing review cover?
Beyond price, cover what the licence lets you do at the boundary and on the way out. Specifically: whether your extensions void support where your code meets theirs, what happens to customisations across a major version, what notice you get on deprecated interfaces, and what an export actually contains.
Ask to see a real export from a real tenant rather than a schema description. Export rights appear in most contracts; exports you can reconstruct a working system from are considerably rarer, and that gap is what makes a licence hard to leave.
Is custom software always more expensive than off-the-shelf software?
No, and the comparison is usually made in a way that guarantees the wrong answer. Custom software costs more up front in nearly every case. Whether it costs more in total depends on how long the system runs, how many seats the bought alternative would need, and how much workaround effort the bought alternative would generate.
We publish no figures for either, because any number offered before someone has examined your integration surface and your data is an opening position rather than a price. What is knowable early is the shape of each option and which of them keeps your choices open.
Method and sources
Where a figure appears above it is linked to the document it came from, and where a source has a commercial interest in its own finding we say so in the body copy rather than in a footnote. Our own review worked like this: in July 2026 we read ten pages in full that search engines returned for build versus buy and custom versus off the shelf queries, and recorded for each one its length, the statistics it published, the source it credited, and what its publisher sells. One further document, a consultancy ebook, could not be parsed and is excluded from every count. Search-result ordering is not a measured ranking position and we make no claim about where any page ranks. Everything else here is judgement from our own integration work, and is written as judgement rather than as data.
- Delivering large-scale IT projects on time, on budget, and on valueMcKinsey & Company with the University of Oxford, 2012. Bloch, Blumberg and Laartz. More than 5,400 IT projects. Source of the 45 percent overrun, 56 percent value shortfall and 17 percent existential-risk figures. McKinsey sells transformation consulting. The page blocks automated retrieval but opens normally in a browser
- The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law DistributionJournal of Management Information Systems, 2022. Flyvbjerg, Budzier, Lee, Keil, Lunn and Bester. 4,677 IT projects. Source of the long-tail finding: most projects land near estimate and a minority miss by extreme margins. Open-access full text
- Are 64% of Features Really Rarely or Never Used?Mike Cohn, Mountain Goat Software. Traces the widely quoted unused-features statistic to Jim Johnson’s XP 2002 keynote and reports that the underlying study covered four internal applications and no commercial products. Cohn sells agile training, which is not served by the correction
- The XP 2002 ConferenceMartin Fowler. Contemporaneous account of the conference at which the Standish figures were presented, used here to confirm the venue and the speaker
- Build vs Buy Software: Pros and Cons, Costs, and How to DecideZylo. The most thorough and best sourced page in the set we reviewed, and the source of the licence-utilisation figures referenced above. Zylo sells software that finds and reclaims unused licences, so its findings about unused licences support its product
