Build vs Buy: The AI Software Decision Framework
Nearly a third of organizations have now decided against buying a software product because they could build it themselves with coding agents. The number is 32%, it comes from McKinsey's 2026 global survey on the state of AI, fielded in May and June 2026 across 1,719 respondents in 97 countries, and it is the single most important input to any build vs buy decision you will make this year.
Here is the part that gets left out of the headline. In the same survey, the share of organizations reporting that AI contributed to their EBIT sat at 37%, unchanged from a year earlier. Companies are building more and buying less, and the financial results have not moved.
Those two facts belong together. The cost of writing software fell. The cost of owning software did not.
Most executives who ask me how to run a build vs buy analysis arrive with a spreadsheet comparing license fees against developer salaries. That is the wrong artifact. The decision is not an arithmetic problem, and treating it as one is how companies end up with an internal tool that works beautifully for eighteen months and then quietly becomes the thing nobody can leave, retire, or staff.
This guide gives you the build vs buy AI software decision framework I use with clients: the seven questions that actually determine the answer, a scoring model you can run in an afternoon, the three costs that never make it into the spreadsheet, what the data says about which side wins, and a ninety day sequence that produces a defensible decision instead of a debate that reopens every quarter.
Why the build vs buy question changed in 2026
For twenty years the build vs buy calculation had a stable shape. Building was slow and expensive, buying was fast and constrained, and the tradeoff was time against fit. Coding agents broke the first half of that sentence without touching the second.
McKinsey's data shows where the pressure is coming from. Around two in ten organizations report scaling software coding agents, rising to 31% at larger enterprises. And the organizations getting the most measurable value from AI are the most aggressive builders: among AI high performers, nearly half report deciding against buying at least one product or feature because they could build it in house, compared with 31% of everyone else.
Vendors know this. Gartner has put a number on the exposure, warning that $234 billion in enterprise application software spend is at risk from agentic AI, as agents complete work across systems and the user interface stops being a differentiator. When the interface is no longer the product, a large share of what you used to pay for stops being worth paying for.
What did not change
Three things survived the shift, and they are the three that decide most projects.
Software costs the most after it works. Maintenance, security patching, dependency upgrades, regulatory changes, the migration you will run in year four. Generating the first version faster compresses maybe 30% of the lifetime cost of a system. It does nothing to the other 70%.
Someone has to own it at 3am. An agent can write the code. It cannot be paged, cannot be held accountable to a customer, and cannot decide whether to roll back. Ownership is a staffing commitment, not a technical one.
Your requirements are less special than you think. The single most reliable predictor of a bad build decision is a team that believes its process is unique. Usually two of the twelve steps are unique and the other ten are the same as everyone else's.
What building actually costs
The spreadsheet that compares a $60,000 annual license against three months of engineering time is not wrong about the numbers. It is wrong about which numbers matter.
The three costs nobody puts in the model
Ongoing ownership. A useful internal system is never finished. Budget 15% to 25% of the original build cost every year, forever, just to keep it working: dependency updates, security fixes, changes forced by other systems moving underneath it. This is not a contingency, it is a permanent line item, and it starts the day you ship.
Key person concentration. Internal tools get built by one or two people who understand the whole thing. When they leave, and eventually they leave, you own a system nobody can safely modify. I have watched a company spend more rebuilding a working internal tool than it would have spent on eight years of the vendor license it replaced, because the original author moved on and the code had no readers.
Opportunity cost of your best engineers. The people capable of building the thing well are also the people capable of building the thing that differentiates you. Every quarter they spend on a document workflow is a quarter not spent on the product customers pay for.
There is a fourth cost that is new this year and that most build models still ignore entirely: the running cost of the AI itself. McKinsey found that one in five organizations is already limiting AI use because of operating costs, including token costs, and that high performers report cost constraints on coding agents about three times as often as everyone else. The teams building the most are hitting the ceiling first. If your build case assumes agent inference is free, it is wrong by an amount you have not yet measured.
When building is genuinely right
Building wins in a narrower set of cases than most teams believe, and in those cases it wins decisively.
Build when the capability is the thing customers actually pay you for. Build when your process is a real source of advantage and bending it to fit a vendor would destroy the advantage. Build when no adequate product exists, which is rarer than claimed but does happen at the edges. Build when the data cannot leave your environment for reasons that survive contact with a lawyer, not just an opinion. And build when the total addressable spend is large enough that vendor pricing becomes structurally irrational at your scale.
Notice that four of those five are about strategy and one is about cost. If your build case rests only on the cost argument, it is probably a buy.
What buying actually costs
Buying has its own hidden ledger, and the people who have been burned by a vendor tend to overcorrect toward building without pricing this side honestly either.
Configuration and implementation. For most enterprise software this runs one to two times the first year license. The license is the visible number and the smaller one.
Integration. Every connection to another system is its own project with its own maintenance. Five integrations is not one project, it is five, and they break on the vendor's release schedule rather than yours.
Process compromise. You will change how you work to match the tool. Sometimes that is a gift, because the vendor has seen a thousand companies and you have seen one. Sometimes it quietly degrades the thing you were good at. The discipline is knowing in advance which of your steps are sacred and which are just habit.
Switching cost. The number that matters is not what you pay per year, it is what it costs to leave. If leaving is expensive, every renewal is negotiated from a position of weakness, and the vendor knows the shape of that curve better than you do.
Vendor risk. The product gets acquired, the pricing model changes, the roadmap moves toward a segment you are not in, the company gets a new owner with a new margin target. None of this is hypothetical and none of it is in your model.
The AI pricing trap
There is a specific version of this worth naming, because it is being written into contracts right now. Vendors are moving from seat based pricing toward usage or outcome based pricing as agents replace interfaces. That shift is rational and probably permanent, but it transfers volume risk from the vendor to you.
Before signing anything with consumption pricing, model your bill at three times current volume and ask what the unit price does at that level. If the contract has no committed ceiling and no price protection, you have not bought software, you have bought exposure. The same discipline applies to any AI feature priced per action, per document or per token.
The build vs buy AI software decision framework
Seven questions. Score each from 1 to 5, where 5 favors building. This is the framework I run with clients, and it takes an afternoon, not a quarter.
1. Is this capability a source of competitive advantage?
Would a customer notice, and care, if this worked differently from your competitors? If the honest answer is no, you are looking at infrastructure, and infrastructure gets bought. Score 5 only if you can name the customer-visible difference in one sentence.
2. How stable are the requirements?
Requirements that change monthly favor buying, because a vendor amortizes that change across its whole customer base and you amortize it across yourself. Requirements that are stable and specific favor building. Score high for stable and unusual, low for volatile or generic.
3. Who owns this in year three?
Not who builds it. Who maintains it when the original team has moved on. If you cannot name a function, a budget line and a headcount, you are not choosing to build, you are choosing to accumulate a liability. Score 1 if there is no named owner, regardless of how good the build case looks otherwise.
4. What does the data actually require?
Some data genuinely cannot leave your environment. Much more data is claimed to be in that category by people who have not read the contract or the regulation. Separate the real constraints from the cultural ones before scoring this, because "we cannot send this to a vendor" is the single most common unexamined assumption in these decisions.
5. How good is the available market?
Three credible vendors means a competitive market and reasonable pricing. One vendor means you are pricing a monopoly, and building becomes more attractive as a negotiating position even if you never do it. Zero adequate vendors is a genuine build signal, but verify it by running an actual evaluation rather than by asking your team whether anything good exists.
6. What is the cost of being six months late?
Building takes longer than the estimate, including now. If the capability is blocking revenue, buy the interim solution and revisit. The pattern of buy now, build later when the requirements are known is underrated and frequently the correct answer.
7. What does leaving cost, either way?
Ask it in both directions. What does it cost to leave the vendor in three years, and what does it cost to retire the internal system in three years. Most teams model the first and never model the second, which is exactly backwards, because internal systems are harder to kill than vendor contracts.
Reading the score
Add the seven scores for a total between 7 and 35.
Above 28: build, and staff it properly from day one with a named owner and a maintenance budget.
Between 18 and 28: assemble. This is where most companies actually sit and where the next section applies.
Below 18: buy, and put the energy you saved into the implementation and the exit clause instead.
The scoring exists to make the argument explicit, not to remove judgment. When a stakeholder disagrees with the total, the productive question is which specific question they score differently and why, which is a far better conversation than arguing about the conclusion.
The third option most companies should choose
The build vs buy framing is a false binary, and the false binary is responsible for a large share of bad outcomes on both sides. The real choice has three doors.
Buy the commodity, build the difference. Buy the platform, the storage, the model access, the authentication, the workflow engine. Build the thin layer that encodes what makes your company work: your rules, your data model, your judgment. This is what most competent AI implementations look like in practice, and it is why the build vs buy debate so often produces a worse answer than the one people were already implicitly following.
Buy now, build later. Take the vendor solution to remove the immediate pain, learn what you actually need from twelve months of real use, then decide with information instead of speculation. The cost of a year of license fees is almost always lower than the cost of building the wrong thing, and it is dramatically lower than the cost of building the wrong thing and having to keep it.
Build the prototype, buy the production system. Use coding agents to build a working version fast, use it to write requirements that are grounded in reality rather than in workshops, then take those requirements to the market. A prototype built in two weeks is the cheapest specification document you will ever produce, and it changes the vendor conversation completely because you now know exactly what you are asking for.
The layer test
When a system is genuinely hard to classify, split it into layers and score each one separately.
The infrastructure layer, meaning compute, storage, models and identity, is almost always a buy. The capability layer, meaning search, extraction, workflow and analytics, is usually a buy with configuration. The logic layer, meaning your rules, your definitions, your exceptions, is usually a build. The interface layer sits wherever your users actually are.
Most failed build projects rebuilt the infrastructure and capability layers on the way to the logic layer, because the logic layer was the only part that needed building and it was easier to start from scratch than to integrate. That is the specific mistake to watch for, and coding agents have made it much easier to commit because the first eighty percent now feels almost free.
What the evidence says about who wins
Two datasets point in directions that look contradictory until you read them carefully.
MIT's Project NANDA studied enterprise generative AI deployments and reached a widely cited conclusion: roughly 95% of enterprise AI pilots delivered no measurable return. Inside that finding sits a build vs buy result that got less attention. Tools bought from specialized vendors and adapted with the vendor reached successful deployment about two thirds of the time. Internally built tools reached deployment about a third of the time. Buying outperformed building by a factor of two.
McKinsey's 2026 survey, meanwhile, shows the highest performing organizations building more than everyone else, not less.
Both are true, and the resolution is not complicated. Organizations with real AI capability, a named owner, a maintenance budget and redesigned workflows build successfully. Organizations without those things build a demo and call it a system. The variable that predicts the outcome is not the choice between building and buying, it is whether the organization has the operational discipline to own what it creates.
Which means the honest version of the question is not "should we build or buy this." It is "are we the kind of organization that can own software," and that question has an answer you already know.
The uncomfortable diagnostic
Look at the internal tools you built in the last three years. How many are still maintained by someone whose job it is to maintain them. How many have documentation a new hire could use. How many have a decommissioning plan.
If the answer is zero across all three columns, your organization is not currently able to build. That is a fixable condition, and fixing it is a legitimate strategic project, but it is not fixable inside the timeline of the decision you are making this quarter.
There is a related failure mode worth checking at the same time, because it distorts every build vs buy conversation: work already happening on unsanctioned tools that nobody has counted. I have written separately about how to find and manage shadow AI inside a company, and it is worth doing that inventory before you decide, because teams that have quietly solved a problem with an unapproved tool are telling you something about requirements that no workshop will surface.
Total cost of ownership over three years
Model both options over three years, not one. One year models make building look cheap because the first year is the only year where building looks cheap.
The build column
Initial development, including the AI operating cost of building it. Infrastructure and hosting. Ongoing maintenance at 15% to 25% of the initial build annually. Feature development after launch, because you will not stop. Security, compliance and audit work that a vendor would otherwise absorb. Documentation and knowledge transfer, which is usually zero in the model and never zero in reality. The salary loading of whoever answers when it breaks.
The buy column
License fees across three years, including expected escalation, because 5% to 10% annual increases are normal and rarely modeled. Implementation and configuration at one to two times the first year license. Integration work per connected system. Internal administration, which is typically 0.2 to 0.5 of a full time equivalent for a serious platform. Training as people join. The cost of the process changes the tool forces on you.
The line most models are missing
Add a third column: expected cost of exit in year four, for both options.
For buying, that means data extraction, format conversion, parallel running and re-implementation. For building, it means the rewrite that happens when the original stack ages out or the original author leaves.
When you run these three columns honestly, buying usually wins on total cost at small and medium scale, and the gap narrows or inverts at large scale or where the capability is genuinely core. Which is roughly what you would have guessed. The value of the exercise is not the answer, it is that the assumptions are now written down and can be challenged by someone who disagrees.
If the numbers on your build column look too clean, that is usually a signal rather than a result. The same modeling discipline that applies here applies to any AI investment, and I have laid out the full cost structure in the guide on enterprise AI adoption.
Governance: the part that decides year two
Whatever you choose, the decision creates obligations that outlive the people who made it.
If you build, you need a named owner with budget, a documented decommissioning trigger, a security review cadence and a rule about what the system is allowed to do autonomously. If you buy, you need contractual clarity on data use, model training, subprocessors and exit, plus a named internal owner who is not the person who signed the contract.
The single most common gap I find is the missing decommissioning trigger. Almost nobody writes down, at the moment of building, the condition under which the system gets retired. Without it, internal tools accumulate indefinitely, and five years later a company is maintaining fourteen systems that four people understand. Write the trigger while you still like the idea, because you will not write it later.
There is one more clause that matters more every quarter: whether your data is used to train models that other customers benefit from. Ask explicitly, get it in writing, and read what the default says rather than what the salesperson says, because the default in most contracts is not what buyers assume. The broader governance structure that surrounds these decisions is covered in the guide on AI governance for business.
How to run the vendor evaluation, even if you plan to build
Run the evaluation regardless. It is the cheapest market research available and it prices your build case honestly.
Demand a demo on your data, not theirs. The prepared demo proves nothing. Give the vendor a real sample, with your messy naming conventions and your exceptions, and watch what happens. Vendors who refuse are telling you something.
Time the core task with a real user. Not the consultant, not the champion. Someone who will actually use it, doing the thing they do fifty times a day. The number of seconds is the strongest predictor of adoption anyone will give you, and no datasheet reports it.
Ask what happens to your data at the end. In what format, on what timeline, at what cost, fixed today, and whether the export includes activity history or only current records. History is the part with value and the part most often excluded.
Call two references and ask one question. What would you do differently. Every other reference question produces marketing. That one produces information.
Price it at three times your current volume. Especially with usage based pricing. If the unit price does not improve at scale, or if there is no ceiling, you are carrying risk the vendor has priced and you have not.
Even if you build, this process gives you a real benchmark: if a vendor can deliver 80% of the value for 20% of the three year cost, the build case needs to be about the remaining 20% being genuinely strategic, and it needs to say so out loud.
Readiness scorecard: can your organization own software?
One point for each true statement. This measures the probability that a build decision survives contact with year two.
Ownership
- Every internal tool built in the last three years has a named current owner.
- That ownership is in a job description, not a favor.
- There is a maintenance budget line separate from project budgets.
- Someone is on call for internal systems, with a defined escalation path.
Engineering practice
- Internal tools have documentation a new hire could follow.
- There is a code review process that applies to AI generated code.
- Dependencies are patched on a schedule, not on an incident.
- At least two people can safely modify each critical internal system.
Decision hygiene
- We have retired an internal tool on purpose in the last two years.
- We can name the total annual cost of the internal software we already run.
- Build decisions are documented with the assumptions that justified them.
- We track whether shipped internal tools actually got used.
Economics
- We model software cost over three years, not one.
- We include AI operating and inference costs in build estimates.
- We know what leaving each major vendor would cost.
Reading the score
13 to 15: you can build. Apply the seven question framework and trust the result.
9 to 12: you can build selectively, one system at a time, with the ownership gaps closed first.
5 to 8: buy for now and fix the ownership problem in parallel. Building from this position produces assets that turn into liabilities in about eighteen months.
Below 5: buy, and treat the ownership question as a strategic project of its own. This is not a criticism of the engineering team. It is almost always a structural gap in how software ownership is funded, and it is the kind of thing that is far cheaper to diagnose with an outside read than to discover through a failed build, because someone who has seen the pattern repeatedly can usually tell you in a few hours where it will break.
Roadmap: 90 days to a defensible decision
Calibrated for a company between fifty and a thousand people facing a real decision, not a theoretical one.
Days 1 to 30: define and measure
Week 1. Write the problem as a number with a threshold and a date. Not "we need better document processing" but "invoice processing takes 14 minutes per document and costs us X per year, and it needs to be under 4 minutes by March." If you cannot write it this way, stop here, because no framework helps you choose a solution to an undefined problem.
Week 2. Inventory what exists. What tools are already in use, including the unsanctioned ones. What internal systems already touch this process. What the current total cost of ownership is. Most teams discover at this step that they already own two thirds of a solution.
Week 3. Run the readiness scorecard honestly, with the people who would own the result in the room. Score the seven framework questions independently, then compare where people diverge. The divergence is the real content.
Week 4. Build the three year model for both paths, including the exit column, and write down the assumptions where the two paths differ most.
Days 31 to 60: test both paths
Week 5 and 6. Run a real vendor evaluation with three vendors, on your data, timed with real users. Do this even if you are ninety percent sure you will build.
Week 7 and 8. Build a prototype of the differentiating layer with coding agents. Two weeks, timeboxed, no exceptions. The goal is not a product, it is to learn where the actual difficulty sits, which is almost never where the team predicted.
At the end of week 8 you have something rare: a priced vendor option and a real measure of the build effort, obtained in parallel rather than sequentially.
Days 61 to 90: decide and commit
Week 9. Score the framework again with what you learned. Scores move at this stage, and the movement is the most valuable output of the whole exercise.
Week 10. Make the decision and write it down: the choice, the assumptions, the owner, the budget, the review date, and the condition that would reverse it. One page.
Week 11 and 12. Commit properly. If you buy, negotiate the exit clause and the price protection before signing, not at renewal. If you build, staff the ownership before writing production code, not after.
At day 90 you do not have a finished system. You have something more useful: a decision that will survive the next executive who asks why you chose this, and a written condition under which you would change your mind.
Four cases from my own work
Different sectors and sizes, to show that the method holds rather than the product. All anonymized by industry.
A sports distribution company. The problem was not which system to buy. Sales data and marketing data lived in separate worlds and nobody saw the customer whole. We unified the data layer and built the segmentation on top of it, which was the only part that needed building. Sales grew 30%. The underlying platforms did not change, what changed was what ran on them and who read the numbers.
A hotel. Revenue was flat around 9 million. The management system existed and worked, but nobody was crossing occupancy against booking channels, and pricing decisions were made on instinct. We restructured the reporting and the dynamic pricing policy. Revenue moved to 10 million without adding a single room, and none of it required new software.
A medical center. The bottleneck was scheduling and cancellation recovery, with staff running informal procedures to refill freed slots. We formalized and rebuilt the booking and recovery flow. Delivered capacity rose 20% with the same facility, no new equipment and no new physicians.
An agritourism business. Small operation, no structured systems, everything driven by personal initiative. Here sequence mattered more than anywhere else: we defined the guest acquisition and management process first, then chose the minimum tool that supported it. Guests doubled.
The common thread is the same in all four. In none of them did the result come from a software feature. It came from deciding first which number had to move, then building or buying around that decision rather than around a vendor's catalog.
If you recognized your own situation more than once in those four, the useful question is not whether to build or buy. It is which decision you are currently making without data, and that is the kind of knot worth untangling before you commit a three year budget to either path.
What to do Monday
Three actions, none of which requires a budget.
Count your internal systems. List every internal tool your company runs, with its owner and its annual cost. Most companies cannot produce this list, and the act of trying is more informative than any framework, because it shows you what you have already implicitly decided.
Write the problem as a number. One sentence, with a current value, a target and a date. If you cannot write it, the build vs buy question is premature and every hour spent on it is wasted.
Score the seven questions. Fifteen minutes with the three people who would own the outcome. Not to reach agreement, but to find out where you disagree, because that is where the actual decision is hiding.
The rest follows from those three. Where the answer turns out to be buy, the evaluation discipline matters more than the shortlist, and I have laid that out in the guide to choosing enterprise search software. Where it turns out to be build, the constraint is almost never engineering capacity, it is process clarity, which is the subject of the guide on business process automation.
And if the feeling at this point is that the problem is bigger than the tool, that is usually the correct reading. It means the build vs buy question is a symptom of an unresolved decision about what your company should be good at, and that is exactly the kind of work worth structuring with someone who has run the decision before, while there is still room to change course and no contract has been signed.
FAQ
What is the right build vs buy AI software decision framework?
Score seven questions from 1 to 5, where 5 favors building: is this capability a source of competitive advantage a customer would notice, how stable are the requirements, who specifically owns it in year three, what does the data genuinely require in terms of residency, how competitive is the vendor market, what does being six months late cost, and what does exit cost in both directions. A total above 28 favors building, below 18 favors buying, and everything between points to assembling, meaning buy the commodity layers and build only the logic that encodes your rules. Score the questions before you look at any vendor pricing, otherwise the framework becomes a justification for a preference you already have.
Is it cheaper to build software now that AI coding agents exist?
Cheaper to write, not cheaper to own. Coding agents compress the initial development phase, which is roughly 30% of a system's lifetime cost, and do almost nothing to the remaining 70% spent on maintenance, security, integration drift and eventual replacement. There is also a new cost that most build models omit: AI operating and inference expense. McKinsey's 2026 survey found one in five organizations already limiting AI use because of operating costs, with the heaviest builders hitting cost constraints on coding agents about three times as often as everyone else. Model three years including maintenance at 15% to 25% of the build cost annually before concluding that building is cheaper.
Does buying really outperform building for AI projects?
On average, yes, and by a wide margin. MIT's Project NANDA research on enterprise generative AI found tools bought from specialized vendors reached successful deployment about two thirds of the time, while internally built tools reached deployment about a third of the time. But the average hides the mechanism. McKinsey's 2026 data shows the highest performing organizations building more than their peers, not less. The variable is not the choice itself, it is whether the organization has named ownership, a maintenance budget and redesigned workflows. Companies with that discipline build successfully. Companies without it produce a demo and call it a system.
What costs are usually missing from a build vs buy analysis?
Five, consistently. Ongoing maintenance at 15% to 25% of the build cost every year, forever. Key person concentration, meaning the rebuild you pay for when the one person who understood the system leaves. Opportunity cost of the senior engineers who would otherwise be working on what customers pay for. AI operating and inference cost, which is new and rising. And the cost of exit in year four, which almost everyone models for the vendor path and almost nobody models for the internal one, even though internal systems are considerably harder to retire than contracts are to cancel.
When should a company definitely buy instead of build?
Buy when the capability is infrastructure rather than differentiation, when requirements are volatile, when three or more credible vendors compete for your business, when being late has a revenue cost, and above all when you cannot name the person and the budget that will own the system in year three. That last one overrides everything else. A strong build case with no named owner is not a build decision, it is a deferred liability, and the cost of it lands two years later on someone who was not in the room.
What is the third option between build and buy?
Assemble, and it is where most companies should land. Buy the commodity layers, meaning compute, storage, model access, identity and the workflow engine, and build only the thin layer that encodes your rules, your data model and your exceptions. Two useful variants exist: buy now and build later, where a vendor removes the immediate pain while twelve months of real use tell you what you actually need, and build the prototype then buy the production system, where a two week agent built prototype becomes the cheapest and most accurate requirements document you will ever take to the market.
How long should a build vs buy decision take?
Ninety days for a decision of real consequence, and the sequence matters more than the duration. Spend the first thirty days defining the problem as a number and inventorying what you already own. Spend the next thirty running a genuine vendor evaluation and a timeboxed two week prototype in parallel, so that you price both paths with evidence rather than estimates. Use the last thirty to score the framework again, write the decision on one page with its assumptions and its reversal condition, and commit properly. Decisions that take longer than a quarter are usually stuck on an undefined problem, not on missing analysis.
Should our data being sensitive automatically mean we build?
No, and this is the most common unexamined assumption in the entire decision. Separate genuine constraints, meaning specific regulatory or contractual requirements you can cite by name, from cultural ones, meaning a general discomfort with data leaving the building. Real constraints are often satisfiable by a vendor through regional hosting, contractual controls on subprocessors and explicit terms on model training. What you should always do, whichever path you choose, is ask in writing whether your data is used to train models shared with other customers, because the contractual default is frequently not what buyers assume it is.