Build vs buy software is decided where the two meet
The build vs buy software decision is rarely settled by features or price, and the statistic widely used to settle it does not hold up. The cost that decides it sits at the boundary where the bought system and the built one meet, so price that boundary and name its owner first.
The statistic this debate leans on does not survive checking
One number keeps turning up in build vs buy software arguments, and it comes from a study of four in-house applications. No commercial product was in it. You will have met it in this form: 85 to 90 percent of the features in bought software go unused.
It is persuasive. If you pay for a product and use a tenth of it, the case for building only what you need writes itself. So we followed it back to where it started.
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 by Jim Johnson, then chairman of the Standish Group, at the XP 2002 conference. He presented 45 percent of features as never used and 19 percent as rarely used. Added together, those give the often-quoted 64 percent. The 85 to 90 percent version inflates a claim that was already specific.
The sample is the bigger problem. 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 advice to anyone citing it to imply that products generally carry that share of unused features is, in his word, to stop.
So a finding about four bespoke in-house applications is routinely used as the central argument for commissioning bespoke in-house applications. Read at face value, it is evidence about the risk of building features that were never asked for. That risk sits on the build side of this decision.
The figure may be fading. When we first researched this article in July 2026, two of the pages we read used it. None of the six ranking pages we could open on October 10, 2026 did, which may mean the correction is spreading. It still circulates, so the trail is set out here.
We sell custom software development services for a living, so a statistic that argues for building would suit us. That is the reason we checked it first. We trace every figure to its primary source or leave it out, and the habit has changed our answer before. The same check on ERP failure rates found the most quoted figure in that field traces to a personal estimate given to a magazine in 1998.
We also argue against building more than once below, and in specifics. The projects that go badly for everyone are the ones where a client built something it should have bought. Those projects are unhappy long before they are unprofitable.
None of this means bought products are used efficiently. Zylo’s license data, covered further down, suggests they often are not. It means the number doing the heaviest lifting in this debate does not measure what it is asked to measure.
Most of the advice comes from someone selling an answer
Almost everyone who writes about build vs buy sells one of the answers, and the advice tends to follow the product. We counted. The eight pages Google ranked for “build vs buy software” on October 10, 2026 were our sample, and for each one we recorded who published it and which way it leans. Six of the eight opened. A Reddit thread and a Medium post could not be read.
Three of the six were published by software vendors, one by a custom development firm and one by a technology consultancy. The sixth was a Forbes Technology Council post by a company chief executive.
The vendor of a no-code platform recommended building, on a platform like its own. The custom development firm leaned toward building and closed by inviting the reader to talk to its experts. A vendor of marketplace and billing software called purchasing the smart choice for companies whose expertise is not large-scale software development.
None of the six stated that its publisher profits from one answer. The nearest was the SaaS management vendor Zylo, which wrote that “the vendors ranking for this topic each have a stake in yours” without naming its own. Two published build cost figures, one a range and one a worked example. Neither named a source for them.
Two more counts shaped the rest of this article. Five of the six mentioned integration, and only one said who carries it once it is live, in a single sentence: your own developers. Three touched on lock-in or switching. None gave the cost of reversing the decision more than a table row, a bullet or a sentence.
This is six pages on one day, a count and not a study of the whole subject. It was enough to show us where the published advice is thin, and those two gaps are where this article spends most of its time. The same check applies to every page you read, this one included: read the recommendation, then look at what the publisher sells.
A school that would have bought, by the usual rules
By the usual rules, one of our clients should have bought, and building was still the right call. A progressive, values-led school in India needed a new website. A content management system is the classic buy case. Mature products exist, they are cheap to start, and almost every organization uses one.
The school chose a CMS built around how it describes itself, instead of an off-the-shelf one. We built a twelve-page Next.js site with that custom CMS behind it and a media server. We deployed it on the school’s own VPS, with the DNS, SSL, documentation and a full handover.
The reason shows in the admin panel. It mirrors the site: 11 pages, 77 sections and 485 editable fields, each one where an editor would expect it. The people updating the site know exactly what they are changing. A generic CMS would have given them a page builder and a list of blocks to interpret. Around that sit the things a busy office needs: draft and publish, autosave, version history and a one-time-password reset.
Building meant the school took on what buyers usually hand to a vendor. It owns the hosting and the server. Its requirements evolved through several review cycles during the build, and every change was a decision someone on its side had to make. By the client’s account on Clutch, the project was delivered within the agreed timeline and the school’s team now runs it independently.
The client also told Clutch what it would change: a more structured content validation step at key milestones. That is what building costs the buyer. When the system is shaped around you, checking that the shape is right is your job as much as the builder’s. It has to happen at every stage, and once at the end is too late.
Two things made custom the right call there, and both apply beyond schools. The way the school presents itself was the purpose of the site, so a generic shape would have diluted it. And the handover, the documentation and the school’s own server kept the decision reversible. The rest of this article is about those two things: which part of a system is yours, and what it takes to undo the choice.
Custom software vs off the shelf, and the path between them
The difference between building and buying software is who carries the cost of the product over its life. Buy, and a vendor carries it for many customers at once while you accept their shape. Build, and you carry it alone, in exchange for a system shaped to you. The school carried it alone for one website. Most organizations face the same choice across a whole estate, and most end up on a third path.
Buying off the shelf means licensing a product built for many organizations: a commercial package or, more often now, a subscription. Somebody else pays to build it, secure it and keep it current. You configure it within the range the vendor chose to expose, and you accept the workflows it assumes.
That trade is usually a good one. The product has already survived thousands of other organizations, their edge cases and their auditors. That is a great deal of hardening you do not pay for.
Building custom software means commissioning a system shaped to how your organization works. There is no workaround to maintain, because the system was designed for you and for no other customer. 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 building is strongest where the process itself is the advantage. Suppose the way you route work, price a job or schedule a plant is what sets you apart. Encoding it in a product designed around someone else’s assumptions dilutes the thing that makes you competitive.
The third path is to buy and extend. 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 a bought back end. It is the pragmatic answer, and most organizations arrive at it whether or not they chose it. It also puts your code and a vendor’s product in the same critical path.
All three paths end with a boundary somewhere, between the bought thing and the built thing, between your data model and theirs. You will have a boundary whichever path you take. What you choose is where it goes and how much of it you are willing to own.
The boundary is where the money goes
Most of the money in a build vs buy decision goes into the boundary between the bought system and the built one, because that is the part no comparison prices. Comparisons of custom software against off-the-shelf software cost both columns in detail: license fees, implementation, developer time, maintenance, training. The space between the columns is costed at nothing. In a two-column comparison it does not appear.
(opens full size in a new tab)The decision also never lands on a clean slate. Your organization already runs bought packages and built systems, with data moving between them and someone who gets called when that movement stops. Whatever you choose becomes the next piece of that estate. So the larger question is what the estate should look like in three years, and which parts of it you intend to own.
In practice the space between the columns 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 right when both hold a version of the same customer. Something has to handle the record the vendor’s product accepts and yours rejects. Someone has to be reachable when that fails on a Sunday.
This is ordinary integration work, well understood by the people who do it. The trouble is that it is almost never in the business case. It gets funded from contingency, delivered under time pressure and owned by whoever happened to build it. Over time it becomes one of the most critical parts of the estate and one of the least documented.
It is also the line that most often explains why two quotes for the same build are far apart. The custom software development cost guide takes that apart line by line.
The boundary costs more than its estimate for reasons a feature comparison cannot show. The first is that it has a running cost as well as a build cost. An integration does not complete the way a deliverable does. It is a small piece of production software with monitoring, a failure mode, an alerting policy and a person who owns it. Organizations 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 ships when it suits its roadmap. A field changes meaning, an endpoint is deprecated, a sign-in method is retired with two quarters of notice. Each is a small piece of unplanned work landing on a team that was doing something else. You did not choose the timing and you cannot decline it.
The third is that accountability blurs at the boundary. 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.
Someone has to own the whole path end to end. If that person was not appointed at the start, the role falls to whoever is most senior in the incident channel.
For that reason we treat build versus buy as an architecture question more 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. Those questions can be answered in advance, and answering it often changes which product you should buy.
One boundary problem is big enough to have its own treatment: two systems holding the same record and disagreeing about it. We wrote that up for running an old system and a new one side by side, and the rules transfer directly. Decide the divergence policy before the systems are live. The first incident is the wrong time to write it.
Ask about the boundary before you shortlist
Seven questions about the boundary decide more of the real cost than any feature comparison, so ask them before you shortlist products. They are quick to put to a vendor. They also 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 record? 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 will drift apart, and the reconciling never ends.
- What does the integration cost to run, as distinct from what it costs to build? Ask for the monitoring, the alerting, the expected failure modes and the person on call. A boundary with no named owner has one anyway: whoever answers the incident, improvising.
- Who absorbs a breaking change when the vendor ships? Find the notice period your contract gives you, and who does the work when it arrives. It is unplanned effort you have agreed to accept, so it belongs in the plan.
- What do you owe the vendor once you extend the product? Ask what happens to your extension when they rebuild the module it hangs off, whether your customizations survive a major version, and whether support is void where your code touches theirs.
- How does your data leave, in what format, on what notice? Export rights are usually in the contract; useful exports often are not. Ask to see a real export from a real customer account before you sign. A schema description is not enough.
- Which team is accountable for the path end to end? That means the whole path from the user’s action to the record landing, and not each component separately. Name that team while everyone is still friendly.
- What would it take to reverse this in three years? Describe the exit in one sentence for both directions: replacing the bought product, and retiring the built one. If either sentence cannot be written, you are choosing one option and closing the other.
A vendor that answers all seven precisely has shown you how it operates. Treat evasiveness on the fifth, the export question, as an answer too.
Is it cheaper to build or buy?
Buying is almost always cheaper up front. Whether it is cheaper over the life of the system depends on how long the system runs, how many seats the bought option needs, and how much workaround effort it creates. There is real research on this. It says less than the confident numbers in circulation, and what it does say describes risk on each side without picking one.
Start with what a build costs. Clutch, the review platform, puts the typical software project reviewed on its platform at 10,000 to 49,000 US dollars, and the average at 132,480 US dollars over about 13 months. The average sits far above the typical band because a tail of large projects pulls it up. Integrations and migrated data are the kind of work that moves a system toward that tail.
If you build in house, the cost is people. The US Bureau of Labor Statistics put the median software developer’s pay at 135,980 US dollars a year in May 2025, before benefits and overheads. The system will need people like that for as long as it runs.
Then the risk on the build side. McKinsey, with the BT Centre for Major Programme Management at the University of Oxford, studied more than five thousand large IT projects. They ran on average 45 percent over budget and delivered 56 percent less value than predicted, and 17 percent went badly enough to threaten the organization itself. Check the definition before you apply it. Their threshold for a large project is well above what most mid-size organizations commission, so this is evidence about big programs and not about every build.
The shape of the outcomes matters more than the average. Peer-reviewed work on IT project overruns across 4,677 projects found a long tail where you might expect a predictable middle. Most projects land near their estimate and a minority miss by extraordinary margins.
So ask what would put your build in the tail, and leave the average alone. The answers are familiar: unclear scope, a data migration that was never surveyed, and sheer size. They are the same three that dominate ERP budget overruns, the most studied version of this problem.
On the buying side, the useful evidence is about what happens after the signature. The SaaS management vendor Zylo publishes an annual index. Its 2026 edition, as Zylo’s own build vs buy page cites it, found organizations use just 54.4 percent of the licenses they pay for. It also found that a large majority of IT leaders met costs they had not expected after signing.
Zylo’s interest needs stating. It sells software that finds and reclaims unused licenses, so a finding that licenses go unused supports its product. That does not make the finding wrong. It does mean it should not be your only source.
Put together, the evidence supports something narrower than either side would like. Building at scale carries a tail risk that buying does not. Buying carries a drift risk that building does not, where cost builds up through licenses, seats and add-ons that are never revisited. Neither finding tells you which to choose for a particular system, and any article that uses them to do so is overreaching.
What both sides underestimate
Buyers underestimate configuration, administration and drift. Builders underestimate maintenance and the people needed to keep a system alive. Total cost of ownership is where most comparisons end and where they are thinnest, and the two blind spots are different in kind.
(opens full size in a new tab)What buyers underestimate
Configuration is work, and at enterprise scale it is often a project of its own. So is the administration a serious product needs once it is live. Someone owns permissions, someone owns 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 are removed. A module that was optional becomes necessary. A renewal arrives with an uplift, and by then the product is embedded too deeply for the negotiation to be a real one. Little of this is hidden, but it is spread across enough small events that no one experiences it as a decision.
What builders underestimate
The build is the visible part of the cost, and the larger part comes after it. That means security patching, dependency upgrades, browser and platform changes, and compliance updates when a regulation moves. It also means the slow stream 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 for as long as it runs. That is a commitment to hiring, to retention and to documentation. Some organizations answer it with a team that stays with the product in place of a hiring round.
The school answered it with a documented handover, so its own team could run the system. Organizations that build without deciding who maintains the system usually find out during a resignation.
One asymmetry distorts the comparison in a known direction. Bought software is a visible line item that finance reviews every year. Built software spreads its cost across salaries, cloud bills and opportunity cost, none of them labeled with the system’s name. So the bought option looks more expensive than it is, because it is easier to see.
Is it better to build or buy?
For most functions, buying is better, and we say that as builders. Once the boundary questions are settled, the conditions for each path are fairly plain to state.
Buy when the function is common to your industry and your process has no advantage encoded in it. Buy when compliance or security expectations are heavy and a vendor already carries them, or when you are short of time more than budget. Accounting, payroll, email, helpdesk and most of CRM sit here for almost everyone. Where a company’s customer records do not fit the standard shape, our custom CRM development page sets out the test we use.
Build when the process is the differentiator, or when integration density is high enough that you would be writing most of the logic anyway. Build when a regulator expects something no product models, or when the workarounds your team has piled up are now the cost. If people keep spreadsheets to survive the product, the product does not fit.
Buy and extend when a product covers most of the requirement and the rest is yours. The vendor also has to expose an extension surface that holds up outside the sales material, so check that surface before you commit. This path fails without much warning when the extension points turn out 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 every year. | 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 | 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 piled up. | 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, the requirement usually has not been split finely enough. Few requirements are a single thing. Most are a common core with a distinctive edge. Draw the line between those two parts before you award the whole requirement to one column.
So 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 where you compete, build that part and buy around it. Either way, price the boundary as a line with an owner and keep it out of contingency.
What it costs to change your mind
Changing your mind later costs more than most plans allow. Replacing a bought product is gated by data, and retiring a built one by knowledge.
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 ordinary, and a product now does it better than your code.
The two directions are not equally hard, and part of choosing well is knowing which one you are making harder.
Replacing a bought product is gated by data and by habit. The data has to come out in a form that means something, which brings you back to the export question. Every integration built against the product has to be rebuilt against its replacement. The deeper the extension work went, the more of it belongs to a vendor you are leaving.
Retiring a built system is gated by knowledge. The rules encoded in it are often the only written record of how the business works. The people who know why a particular condition exists may have left. Migration becomes archaeology before it becomes engineering, and the archaeology is the part that overruns.
So write contracts and code with the exit in mind. When buying, the exit terms matter more than the feature list, because features converge and exit terms do not. When building, documentation, a clean data model and code you hold yourself are what keep the decision reversible. The school’s handover and its own server did that job. Both cost little while the decision is open, and a great deal once it is made.
Before you sign either way, write down what reversal looks like in both directions. It takes an hour and costs nothing. It is far harder to write once an estate has stopped fitting the business it serves.
For a decision you are weighing now, send us the requirement and the products on your shortlist. On a 30 minute call, the people who would build it will tell you where they would draw the boundary. If buying is the better answer they will say that, and you keep the answer even if you never work with us.
Questions buyers ask about build versus buy
Is it better to build or buy software?
For most functions, buying is better: accounting, payroll, email, helpdesk and most CRM are common to every organization, and a vendor has already absorbed the compliance and security work. Building is better when the process itself is your advantage, when no product models what a regulator requires, or when your team already runs a layer of spreadsheets to make a product work. Many organizations buy the common core and build the distinctive edge.
Is it cheaper to build or buy software?
Buying is almost always cheaper up front. Over the life of the system it depends on how long it runs, how many seats the bought option needs, how much workaround effort it creates, and the cost of maintaining a build. Compare both over the same multi-year period, and remember that bought software is a visible invoice while built software hides in salaries and cloud bills, which makes buying look dearer than it is.
What is the difference between building and buying software?
Buying means licensing a product built for many organizations, configured within the limits the vendor sets, with the vendor carrying its development and upkeep. Building means commissioning a system shaped to your own processes, where you own the code, the data model and the roadmap and carry their cost for as long as the system runs. Most estates also use a third path, buying a platform and extending it.
What are the pros and cons of build vs buy software?
Buying gives speed, a product hardened by many other organizations and a predictable line item, at the cost of fitting your process to someone else’s assumptions and roadmap. Building gives exact fit, ownership and control of the schedule, at the cost of maintenance, staffing and a real risk of overrun. What usually decides it is missing from both lists: who owns the integration boundary between the new system and everything you already run.
How do you compare total cost of ownership when building versus buying software?
Compare over the same multi-year period and add what each side usually leaves out. For buying: configuration, internal administration, seat growth, renewal uplifts and the cost of leaving. For building: maintenance, dependency and security upgrades, documentation and the people who understand the system. Add the integration boundary as its own line on both sides, with a build cost and a running cost.
What should a software licensing review cover before you buy?
Beyond price, cover what the license lets you do at the boundary and on the way out: whether your extensions void support, what happens to customizations 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 customer account rather than a schema description, because a dump you cannot rebuild a working system from is not portability.
Should a manufacturer build or buy software?
Buy where the ERP or a mature MES already covers the work: production planning, inventory and quality records are standard modules. Build where the plant does something those systems do not model, such as a scheduling rule, a step in capturing floor data or the link between the machines and the ERP, and build it beside the ERP rather than in place of it. Our manufacturing software development page sets out where that line usually falls.
The author
