Buy vs Build for AI in the Mid-Market: What the Success-Rate Data Says

In August 2025, MIT's NANDA initiative published The GenAI Divide: State of AI in Business 2025, and the number that grabbed every headline was that about 95% of enterprise GenAI pilots showed no measurable P&L impact. The more useful finding sat a few pages deeper and got a fraction of the attention. MIT found that when companies bought AI tools from specialized vendors, deployments succeeded about 67% of the time, and when they built the same class of tool internally, the success rate was roughly a third of that.

I spent years running product engineering and AI teams at American Express, and I've spent the time since advising mid-market companies on AI adoption, and that ratio matches what I see on the ground. The build-it-ourselves instinct runs strong, especially in companies proud of their engineering culture. The data says it's the wrong default for most of them. So this piece is about the economics behind the gap, why the gap is wider for mid-market firms than for the enterprises MIT studied, and the narrow set of cases where building is still the right call.

What the data actually says, and its limits

The honest caveats first, because this report got quoted everywhere and misread almost as often. The MIT NANDA team based its findings on 150 interviews with leaders, a survey of 350 employees, and an analysis of 300 public AI deployments. It isn't peer-reviewed research, the sample skews toward larger organizations, and "success" means the tool made it into real production use with measurable impact, not that it transformed the company. Treat the exact percentages as directional rather than gospel.

Directionally, though, the finding lines up with everything else we have. IBM's 2025 CEO study, run with Oxford Economics across 2,000 CEOs, found that only 25% of AI initiatives had delivered their expected ROI and just 16% had scaled across the enterprise. And the failure pattern MIT describes is consistent throughout: pilots stall because tools don't fit the workflow, don't retain feedback, and never had a defined business outcome attached. Those are exactly the problems an internal team solves for the first time while a vendor has already solved them dozens of times, which turns out to be most of the story behind the gap.

One more thing the 95% figure does and doesn't cover. General-purpose chat tools are widely adopted and genuinely useful for individual productivity, and MIT noted heavy informal use of personal AI accounts even inside companies whose official pilots had stalled. The expensive failures cluster in custom and embedded initiatives, the ones where someone budgeted real money and expected a line-item return, and that's the territory where the buy-versus-build decision lives.

Why the gap gets wider below the enterprise

MIT's sample leaned toward large organizations, which makes the numbers more sobering for mid-market companies, because every force behind the gap hits harder when you're smaller. Four of them compound.

Talent you can't hire, or keep

In the hiring markets I see, a competent ML engineer runs somewhere between $200,000 and $350,000 fully loaded, and the strong ones want to work alongside other strong ones, on hard problems, with modern infrastructure. A mid-market firm can afford maybe one or two. That means your internal build carries a bus factor of one, gets no review from anyone who has shipped this before, and quietly inherits whatever architecture the engineer wanted to learn next. At American Express we had entire platform teams whose only job was keeping model infrastructure healthy. Most mid-market companies are asking one developer, who usually also owns the ERP integration, to replicate that on the side.

The maintenance burden lands entirely on you

Old software wisdom says most of a system's lifetime cost arrives after version one ships, and AI systems are worse than normal software on this front. Foundation models get deprecated or repriced every several months. Prompts tuned for one model version behave differently on the next. Data pipelines drift, upstream APIs change, and evaluations need re-running every time anything moves. A vendor spreads that ongoing burn across its whole customer base. An internal build means you carry all of it alone, indefinitely, or the tool quietly rots.

Opportunity cost bites harder at your size

If you have eight engineers and an internal AI project absorbs two of them for nine months, a quarter of your engineering capacity just came off the roadmap that wins customers. An enterprise can stand up a skunkworks without the core business noticing, and a two-hundred-person company cannot. The build's true cost includes every feature that didn't ship while it was underway.

Vendors sell you their learning curve at a group rate

This one is the quiet economic engine behind MIT's 67%. A vendor that has deployed its product at two hundred companies has already met the weird edge cases: invoices that arrive as photographed paper, the CRM field half the sales team repurposed, the approval flow that breaks when the controller is on vacation. Every customer's pain became product. When you build internally you rediscover each of those lessons at your own expense, on your own timeline, and MIT's root causes (no workflow fit, no learning from feedback) are the lessons that take longest to rediscover, so you end up paying full tuition for knowledge the vendor amortizes across everyone.

A worked example with honest numbers

Say your AP team processes 4,000 invoices a month and you want AI-assisted extraction, matching, and approval routing. On the build path, two engineers for six months gets you a credible version one, call it $250,000 loaded. Then budget 30% to 50% of that per year for maintenance, model migrations, and the breakage that follows every upstream change, which is the range I tell clients to plan for. Three-year total: somewhere between $475,000 and $625,000, assuming nothing goes badly and nobody quits.

On the buy path, specialized AP automation at that volume runs a few thousand dollars a month, so call it $75,000 to $150,000 over the same three years, live in weeks rather than quarters, with the edge cases already handled by someone else's painful rollout. For the build to win, your requirements have to be so unusual that no configurable product covers them, and at 4,000 invoices a month they almost never are. The same arithmetic repeats across support triage, contract review, demand forecasting, and scheduling. Mid-market volumes rarely justify bespoke engineering for operational workflows.

What you're actually paying a vendor for

It helps to reframe what the subscription buys. The model itself is close to a commodity now; nearly everyone calls the same handful of frontier APIs underneath. What the price actually covers is integration learning: workflow fit, exception handling, connectors into your systems, an evaluation harness, and continuous updates as the underlying models churn. That last item matters more than people expect. The model landscape has turned over several times since 2023, and vendor customers absorbed those migrations invisibly while every internal build had to schedule its own.

Buying carries real risks, and the answer is to hedge them in the contract rather than retreat to building. Insist on data export in a usable format. Confirm your data won't train anyone's models without explicit opt-in. Avoid long prepaid terms in a category where pricing keeps moving. Check the vendor's runway if they're early stage. A vendor dying on you is a genuine cost, but it's usually smaller and more recoverable than a dead internal project, because at least your engineers spent the intervening year on your own product.

The three cases where building wins

Building can still win, but it has to clear a specific bar, and in my experience three situations clear it.

1. You own a real data moat. You hold data nobody else has, and the system's value comes primarily from that data rather than from general model capability. The test I use is whether a competitor would pay serious money for the dataset. Ten years of pricing decisions with outcomes attached, telemetry from your own installed equipment, claims history in a niche you dominate. If the answer is yes, a vendor tool trained on generic data can't match what you can build, and the build compounds your advantage over time. Note the bar, though. Having data sitting in a warehouse doesn't count. It has to measurably change the system's output in ways a configurable vendor product can't replicate.
2. The workflow is how you win deals. If the process you're automating is the reason customers choose you, renting the same tool your competitor can rent puts a ceiling on that advantage. A distributor whose whole pitch is same-day quote turnaround has a case for building its quoting engine. The same distributor should buy its HR helpdesk bot without a second thought.
3. No vendor category exists yet. Occasionally a workflow is genuinely novel and nobody sells a product for it. Two warnings before you conclude that. First, search harder than feels necessary, because the category often exists under a name you haven't tried, and the market is filling in fast. The US Chamber of Commerce found 58% of small businesses using generative AI in its latest Empowering Small Business report, up from 40% in 2024, and vendors are building into every niche that adoption opens. Second, "no vendor supports our exact fourteen-step process" usually means the process needs simplifying, not that it deserves custom software.

Even when a build clears the bar, build thin. Build only the differentiated layer and buy everything under it: models through APIs, document processing, orchestration, retrieval infrastructure. And treat the build like a product, with a named owner, a maintenance budget, and a roadmap, rather than a project that ends at go-live. Every successful internal build I've seen ran that way.

A decision test you can run in an afternoon

When we work through this question with clients at FirmAdapt, it reduces to five questions an executive team can answer without outside help.

• Is the workflow differentiating or operational? If a competitor doing it equally well wouldn't hurt you, it's operational, and operational means buy.
• Do we have proprietary data that materially changes the output? The bar is data a vendor can't access that provably improves results, and "provably" means you've tested it, since intuition flatters your data more than benchmarks do.
• Who maintains this in year two? Name an actual person who owns model migrations, evaluations, and 3 a.m. breakage. If you can't name one, or the name is the engineer everyone already fights over, buy.
• What does each path cost over three years? Include maintenance at 30% to 50% of build cost annually. Most build proposals I review price version one and stop there.
• What breaks if it breaks? If a week of downtime touches revenue, you want a vendor with an SLA or a properly staffed internal team. A side project maintained between sprints is the worst of both worlds.

If the build case doesn't win at least four of the five, buy. Run honestly, this test sends the large majority of mid-market use cases to vendors, which is where the success-rate data says they should go.

What to do Monday morning

A few moves that follow directly from the evidence.

1. Inventory every AI pilot and subscription you're running. Kill anything without a defined business outcome, since undefined outcomes sit at the top of MIT's root-cause list.
2. Pick one workflow where success would show up in the P&L, and write the metric down before you look at a single tool. "Cut cost per invoice processed by 30%" is a metric. "Explore AI in finance" is a wish.
3. Run two or three vendor pilots against that metric, on short contracts, with a decision date. Good vendors expect this now and will co-design the pilot with you.
4. Reserve build capacity for the one candidate that passes the data-moat or differentiation test. If nothing passes this year, that's a fine outcome, and plenty of companies win with a portfolio that's entirely bought.

The urge to build is understandable, and earlier in my career I shared it. The evidence available in mid-2026 says buy by default, treat building as the exception you argue for with a named owner and a real maintenance budget, and put the energy you save into integration and adoption work, because that's where the successful minority separates itself.