Build vs Buy Software Decision: Price the Run Cost First

Table of Contents

• Quick answer: build versus buy today
• Yes, the 32% Is Real. Start by Conceding It.
• Skipping the Purchase Is Not the Same as Saving the Money
• What the Build Actually Costs to Keep Running
• Year Three: Who Maintains the Tool, by Name?
• The Build vs Buy Software Decision Test: Three Questions Before the Quote
• When Buying Still Wins
• The Third Option the Build-vs-Buy Debate Keeps Missing
• Price the Three-Year Run Cost Before You Approve the Build

Last updated: 2026-11-10

The renewal quote lands on a Tuesday, and it’s higher than last year’s. The vendor’s account manager has already floated a two-year lock to soften the blow. Then someone in the room, usually your sharpest engineer or a newly AI-fluent product lead, says it: “We could just build that now.”

They’re probably right about the capability. The build vs buy software decision used to turn on whether your team could produce it at all. Agentic coding tools mostly settled that question. They didn’t settle who pays to run the result, who fixes it when the model underneath it changes, or who’s still around to answer for it in year three. That’s the decision now.

The scale of the shift is not small. Nearly one-third of respondents (32 percent) in McKinsey’s State of AI 2026 global survey, published in August 2026, said their organizations decided against buying at least one software product or feature because they could build it in-house with agentic coding tools. The short version of what to do about it: build what’s specific to how you work, buy what’s regulated or heavily integrated, and build nothing until you can name its owner 36 months out.

Yes, the 32% Is Real. Start by Conceding It.

The shift is real, and it’s bigger than most vendors will admit. For a narrow internal tool, building is now often the right call. A CEO who waves that away loses credibility with the very engineers who will end up building it anyway. For build vs buy AI 2026 conversations, that concession is the price of being taken seriously.

What agentic coding tools genuinely changed about the first draft

A working first draft of an internal tool used to cost a sprint and a half of senior engineering time. Today an intake form, an approval workflow or a reporting view can exist by Friday. Agentic coding tools write the scaffolding, the tests for the obvious paths and the glue code no engineer wanted to hand-write anyway. AI built internal tools stopped being a novelty somewhere around the point where every department had one, and no announcement went out when it happened.

The adoption data tracks with that. McKinsey found that among AI high performers, nearly half decided against buying software because coding agents could build it in-house, compared with 31 percent of other respondents. AlixPartners, in its 2026 enterprise software predictions, puts the speedup in software development at 20 to 30 percent. Both findings point the same way. The first draft got cheap, and the organizations furthest along noticed first.

A leadership team weighing a vendor renewal against a prototype an engineer built in a few days.

The builds where skipping the purchase is now simply the right call

Build when the tool serves one team, touches no regulated data, and could be thrown away without a board conversation. A commission calculator for a twelve-person sales team. An onboarding checklist that reads from your HR system. A dashboard on top of a database you already own. A one-off reconciliation script that finance runs on the first of the month.

The test isn’t how clever the tool is. It’s how bad a bad day looks. If the tool breaks on a Monday and the damage is an annoyed team doing a manual workaround for a day, the economics are hard to argue with. A packaged product in that category is usually overbuilt for the need anyway, with seats you won’t fill and features your team will never open.

Notice what these examples share. Each has a small blast radius, a clear user and a replacement cost you could absorb. When a tool has all three, the build vs buy software decision pros and cons tilt toward building, and no framework will tell you otherwise.

Skipping the Purchase Is Not the Same as Saving the Money

A cancelled licence disappears from the vendor’s invoice. It doesn’t disappear from your cost base. The work moves to cloud billing, payroll and somebody’s calendar, and those lines are far harder to see than a renewal quote.

The renewal you cancelled versus the cost centre you created

Say you cancelled a five-figure renewal. The vendor’s invoice stopped. In its place you now own an application with a hosting bill, possibly an inference bill, a security posture someone has to defend, and one engineer who knows why it works. None of that arrives with a line in the budget the way the renewal did, which is the only reason it feels cheaper.

Most business cases for building compare the build quote against a single year of licence fees, which gets both sides of the equation wrong. Set three years of licence against the build plus three years of running it. That second number is rarely on hand, and any serious build vs buy analysis has to start by going and getting it.

Why the avoided licence does not show up in the numbers

McKinsey’s survey offers a circumstantial clue. While 32 percent of respondents reported skipping a purchase, 37 percent attribute at least some EBIT impact to AI use, about the same share as the year before. The data doesn’t prove the savings were absorbed elsewhere; those are different questions with different denominators. But if skipping a purchase were a clean saving, you’d expect it to move at least one reported number.

None of that is a verdict on your own books, so go and check them. Pull the last three purchases you skipped and ask finance where each saving shows up in the ledger. If no one can point to a line, what got recorded was a forecast of a saving rather than the saving itself.

Why this bites harder in the mid-market than in the enterprise

The enterprise has a bench. A $1 billion company can fold an orphaned internal tool into a platform team. A 200-person company can’t. According to McKinsey, 40 percent of respondents at organizations above $1 billion in revenue report scaling AI agents, up from 27 percent a year earlier, while the share at smaller organizations stayed flat at 22 percent.

The organizations driving this move are the ones with the engineering capacity to run what they build. A mid-market CEO who copies the decision without that capacity has copied half the plan, and for mid-market internal systems the missing half is the part that keeps the tool alive after launch week.

Consider a 150-person distributor with four engineers, all of them committed to the ERP integration roadmap. Adding an AI-built pricing tool doesn’t add a fifth engineer. It adds a fifth responsibility to the four already stretched, and the roadmap slips by exactly the hours the tool consumes.

What the Build Actually Costs to Keep Running

A build carries four recurring costs that never appear in the quote: hosting and inference, monitoring, security and compliance review, and forced upgrades when a model or API underneath it changes. Each one recurs whether or not anyone ships a feature.

Custom software run cost is already biting. McKinsey found that about 20 percent of respondents say AI-related operating costs, including token costs, constrained their AI use. And AI high performers report being constrained by cost in their use of software coding agents about three times as often as other respondents do. The organizations that built the most are the ones hitting the ceiling first.

Hosting, inference and the monthly floor that never made the quote

Hosting is the cost everyone remembers, and inference is the one they forget. If the tool calls a model, every use carries a price, and usage climbs precisely when the tool is working well. The incentive that creates is a strange one, because a tool nobody likes costs almost nothing to run, while the bill only turns into a problem once the whole company has adopted it.

You’ve turned a one-time project into a variable bill. Whoever owns the cloud account absorbs it, usually IT, usually unplanned. If you’re pricing AI software development cost in 2026, put a usage curve next to the build estimate rather than a flat line, and ask who signs off when the curve bends upward.

Monitoring, the security review and the compliance re-review

Something has to tell you the tool is broken before a user does. That means monitoring, alerting, and a person who reads the alert at an inconvenient hour. Then comes the security review: dependencies, secrets, the access model, the data the tool touches. The OWASP Top Ten is a reasonable checklist for what that review should cover.

A vendor runs these reviews continuously across every customer. Your internal tool gets one when somebody remembers, which is usually after an auditor asks. Regulated data adds a re-review each time the tool changes what it touches. So put security review in the budget as a recurring line item with a frequency attached to it, the way you would an insurance premium.

The upgrade you did not schedule: when the model or API underneath changes

A tool that calls a hosted model depends on a model version its provider will eventually retire. When that happens, the call fails. It doesn’t degrade gracefully into a slightly worse answer. The tool stops until someone updates the model reference, re-tests the outputs and re-tunes prompts that were written against the old behavior.

Treat model and API retirement the way you treat a certificate expiry: a dated maintenance event on a calendar with a named person attached to it. Plenty of AI-built internal tools have no such calendar, because no one was ever asked to open one. The risk isn’t the code you wrote. It’s the ground under it.

Alex Turnbull founded Groove and spent a year building two AI customer-experience products. His verdict: “The myth that one junior dev plus AI can build enterprise software is one of the biggest lies being spread right now.”

The recurring costs that sit outside the build quote: hosting, inference, monitoring, security review and upgrades.

Year Three: Who Maintains the Tool, by Name?

Picture an operations team that builds a quoting tool in a week. Eighteen months later the person who prompted it into existence has moved on. The tool still runs. Nobody can change it. Who maintains internal tools built this way is a question with a name as its only acceptable answer.

Tribal knowledge is not documentation

The prompt history that produced the code sits in one person’s chat tool. It isn’t documentation. Neither is a repository that works because its author remembers which environment variable to set. Tribal knowledge feels like knowledge right up until the person leaves.

A CEO can test this in two minutes. Ask who could ship a fix if the author were unreachable for a month. If the room goes quiet, you have your answer, and you’ve also learned that the tool’s real cost includes a key-person dependency that never made the risk register.

What has to exist before a second person can safely touch it

A second engineer needs six things before touching production without fear:

• Architecture decision records that explain why the system looks the way it does. The ADR community site is a good starting reference for the format.
• An API reference current enough to trust.
• Automated tests covering the paths that matter, so a change can be checked in minutes instead of days of manual clicking.
• A runbook for the three incidents most likely to happen.
• Deploy and credential access held by at least two people.
• An inventory of every model and external API the tool depends on, with known retirement dates.

AI can make several of these cheaper to produce. It doesn’t make them optional, and they won’t write themselves unless the process demands them. Most AI-built internal tools ship with none, because the person prompting the tool was never asked for any.

The Build vs Buy Software Decision Test: Three Questions Before the Quote

Ask three questions in order, out loud, before anyone presents a build quote. Specific to how we work: build. Regulated or heavily integrated commodity: buy. No named owner for month 36: neither, yet.

This is the build vs buy decision framework in meeting-sized form. A CTO can answer each question without translating from architecture, and a CEO can ask them without a glossary. When to build vs buy software stops being a debate and becomes three answers on a whiteboard.

Is this capability specific to how we actually work?

If the capability encodes how your business differs from your competitors, build it. A scheduling rule that reflects your service model. Pricing logic your sales team tuned over a decade. A research workflow no vendor has ever seen.

Packaged software gives you the industry’s average process. You’d be paying to flatten the thing that makes you different. A quick check: if three vendor demos would look identical to your competitor, the capability isn’t specific to you.

Is it a regulated or heavily integrated commodity?

Buy it. When the category is a commodity that carries a compliance surface or depends on a catalog of integrations, the vendor spreads that burden across every customer. You’d carry it alone. Payroll, payments, identity and e-signature all fit.

Both halves matter. A commodity with no compliance surface and few integrations, like a simple internal directory, can go either way, which is why this question comes second and not first.

Can we name the person accountable for it in 36 months?

Name a person. Not a team, not a role. Someone who’s employed today, wants to keep this, and has the time. If the name doesn’t come, the answer is neither build nor buy yet.

Buying a product with no owner fails too, only more slowly, because the vendor at least keeps the code alive. Most build vs buy strategy frameworks never ask this question. It’s the one that decides whether the first two answers hold.

The three questions in order: is it specific to us, is it a regulated commodity, and can we name an owner in 36 months.

If you want a second set of eyes on a specific build quote, see how our architecture assessments price the run cost.

When Buying Still Wins

Buying wins whenever the vendor carries a burden you can’t carry cheaper: a compliance surface, a catalog of integrations, or expertise you can’t hire. Nexa Devs builds custom internal software for a living. We’d still tell you to buy in each of these three cases.

Commodity capability carrying a compliance surface

Payroll tax tables change by jurisdiction. Payment rules change by network. Health data handling changes with every regulator’s guidance. A vendor serving thousands of customers pays for that posture once. You’d pay for it alone and pay again whenever a rule moves.

A build wins the first demo and loses the first audit. If a regulator, an auditor or a customer’s security questionnaire will ever ask who maintains the control, buy the product whose vendor already answers that question every week.

Integration-dense categories where the connectors are the product

A CRM, an accounting platform or an ERP is worth less for its features than for the maintained connectors around it. When a partner changes its API, the vendor fixes it once for everyone. If you build, every change at every partner becomes your ticket.

Buying carries its own risk, and the risk has a name: consolidation. AlixPartners forecasts that AI disruption will force consolidation in mid-market enterprise software, with M&A deal volume rising 30 to 40 percent year over year in 2026 and deal value potentially reaching $600 billion, up from around $440 billion in 2025. Those numbers are projections, and projections move. The practical consequence either way is that your vendor can be acquired, repriced or sunset while you are still depending on it, so data export and exit terms belong in the contract before you sign it.

Capabilities you cannot staff, at any build price

Some capabilities need people you can’t hire or keep: tax engines, claims adjudication, clinical decision support, cryptographic infrastructure. No build quote is low enough if no one on your payroll can maintain the result.

Price the people, not the code. If the honest staffing answer is “we’d need to recruit two specialists we can’t afford,” the decision is made. Buy it, and spend the saved engineering hours on the capability only you can build.

The Third Option the Build-vs-Buy Debate Keeps Missing

The third option is to build only what’s specific to your business, under a process that produces its own documentation, with a partner whose accountability survives launch. It answers the two objections every make-or-buy decision in software raises: can we own what we build, and what happens if the builder leaves?

Build only the part that is specific to the business

A mid-market operations team doesn’t need to build payroll. It needs the dispatch logic, research workflow or lab intake that no vendor models the way the business works. Nexa Devs builds that layer as custom internal software and connects it, through APIs and middleware, to the commodity systems you’ve rightly bought.

That keeps the build small and the surface area honest. The compliance-heavy and integration-heavy parts stay with vendors who spread them across thousands of customers, and your engineers stay focused on what differentiates you.

Documentation, architecture decision records and test coverage as deliverables, not afterthoughts

On every Nexa engagement, AI-assisted requirements analysis and design produce architecture diagrams, system design documentation and architecture decision records as standard deliverables. Claude Code and MCP-based integrations run across the codebase, and unit and integration tests are generated alongside the code in each sprint rather than saved for an end phase.

At completion the client receives the full package: UML architecture diagrams, system design documents, user story libraries, API references in Swagger or Postman, and test coverage reports. All of it is transferred to the client and owned by the client unconditionally, whether the engagement continues or not. The same AI tooling that makes the first draft cheap makes these documents cheap to produce, provided the process requires them.

The handover package that lets a second person safely change a system: decision records, API references and test coverage.

Accountability that does not expire at launch

Every project includes one month of free post-launch support. After that, SLA-based monthly support covers bug resolution, system evolution and continuity. Nexa also supports systems built by other vendors, so the AI-built tool your team assembled last year isn’t disqualified from getting a proper owner.

Long engagements are the proof that the model holds. Nexa has worked with UCLA’s David Geffen School of Medicine for more than ten years, and with TSB and FrontStream for more than eight. Your year-three owner can be an internal sponsor backed by a documented system and an SLA, instead of one engineer’s memory.

Price the Three-Year Run Cost Before You Approve the Build

Make the next business case show 36 months of run cost before it shows the build quote. If the year-three owner has no name, the plain answer is that your organization can’t afford to build it yet.

The 36-month number to take into the next approval

Ask the proposer to fill in six lines, in this order, before anyone sees the build price:

1. Hosting and inference priced at the usage you expect once the tool has caught on, rather than the usage you will see in week one.
2. Monitoring and on-call coverage, with a name.
3. One security review a year, plus a re-review whenever the data scope changes.
4. Every model and API upgrade event, dated on a calendar.
5. Documentation upkeep, so a second person can still touch it.
6. The owner’s time, priced as a fraction of a salary.

Then compare the 36-month total, build included, against 36 months of the licence. If the build still wins, approve it with confidence.

An old rule of thumb helps here. The 40/20/40 rule splits effort roughly 40 percent to requirements and design, 20 percent to coding and 40 percent to testing and integration. AI compresses the 20. The other 80 still needs people. A cheaper first draft doesn’t make the whole project cheap.

What to do when the owner has no name

You have four real options. Buy the packaged product and assign an owner for the vendor relationship. Shrink the build to something you can discard without a meeting. Assign or hire the owner before approving the budget. Or bring in a partner under an SLA, with documentation transferred to you from day one.

What you shouldn’t do is approve the build and hope the owner appears. Whatever the tools can now produce in a week, the thing you’re approving is three years of keeping it alive. If the room can’t name who does that, wait.

If you’re weighing a build quote or a renewal right now, talk to Nexa Devs about pricing the three-year run cost. We’ll tell you plainly whether to build, buy or wait.