Why mid-market AI POCs fail to reach production — the structural diagnosis

Most AI projects we are asked to rescue were not failed prototypes. They were prototypes that nobody planned to put into production. That diagnosis is wrong in a specific way, and the wrongness costs mid-market companies between two and four years of stalled AI investment before the pattern becomes visible from inside. This article is the cluster's structural argument: the reason mid-market AI POCs fail to reach production is not the buyer's maturity. It is what the vendor was paid to do.

What the industry assumes

The dominant explanation for AI implementation failure, across the most influential analyst and consulting publications of the past three years, is that the buyer was not ready. The framing comes in different vocabularies — AI maturity, AI readiness, organisational capability, data foundations, change management discipline — but the structural claim is the same: the technology was sound, the methodology was sound, the failure was in the buyer's organisation.

BCG's 2024 survey of a thousand executives across more than twenty sectors reports that only 22% of companies have advanced beyond the proof-of-concept stage to generate some value, and only 4% are creating substantial value from AI (BCG, 2024). McKinsey's State of AI 2025 finds that nearly two-thirds of organisations have not yet begun scaling AI across the enterprise (McKinsey, 2025). Informatica's 2025 CDO Insights survey reports that 67% of data leaders have not been able to successfully transition even half of their GenAI pilots into production (Informatica, 2025). The numbers are real. The pattern they describe — a wide gap between AI experimentation and AI production — is real. The diagnosis these reports attach to the numbers is what the cluster argues against.

The cost of believing the diagnosis is direct: in the mid-market specifically, the framing has produced a generation of vendor proposals that price readiness improvement as the deliverable. A buyer who believes their AI failure was a maturity failure buys another maturity engagement. They buy a six-month readiness assessment with a strategy roadmap output. They buy an AI governance framework. They buy an AI literacy programme. They are now two to three years into the cycle, the consulting fees are well over a hundred thousand euro, and the production system that started the conversation has not been built.

Where that assumption breaks

The maturity diagnosis is internally consistent given its assumptions. The assumption is that the vendor's incentive is aligned with shipping a production system, and therefore production failure is a buyer-side problem. Inside that assumption, "the buyer wasn't mature enough" is a coherent answer for why a project did not ship.

The assumption fails because, in the mid-market consulting engagement model, the vendor's revenue is decoupled from production outcome. The discovery phase is paid. The pilot phase is paid. The strategy phase is paid. The production deployment is described as a future engagement. The vendor's profitable activity ends before the production system is committed. Inside that incentive structure, a project that produces a paid pilot and never ships is not a failure; it is a successful billable cycle.

What the maturity framing misses is the structural variable. The buyer's organisational capability is one input. The vendor's incentive to ship is another. The reports cited above all measure the buyer-side input. None of them ask the vendor-side question: was the vendor paid to deliver a production system, or paid to deliver a roadmap?

This is the cluster's wedge. The maturity diagnosis is the part of the industry conversation that the analyst class can produce data on. The pricing diagnosis is the part the analyst class is structurally unable to publish, because the analyst class shares incentives with the consulting class. Specifically: large analyst firms are operated by, or partner with, the same firms whose engagement models the cluster argues against.

The four named paradigms the cluster argues against

There are four dominant paradigms operating in the mid-market AI vendor market. Each is carried by named firms. Each has a published methodology. Each one is internally coherent, fits real situations, and breaks specifically in the mid-market industrial context the cluster cares about.

The AI maturity and readiness framing is carried by McKinsey, BCG, Microsoft, and Gartner. Its core argument is that AI efforts stall because organisations lack the governance, data readiness, operating model, skills, and leadership alignment required to scale (McKinsey, 2025). It is correct for large enterprises building repeatable internal AI capability across many business units. It breaks in the mid-market because it turns production failure into a buyer-defect story, which lets vendors avoid accountability for shipping systems with no evaluation harness, no on-call owner, and no operational handoff.

The "POC first, then scale" playbook is carried by Deloitte and the Big Four transformation teams. It is codified explicitly in Deloitte's From AI Pilots to Production publication, which argues that the responsible path through AI uncertainty is staged experimentation — prove the use case, validate the architecture, then scale (Deloitte, 2024). It is correct in regulated or capital-intensive settings where irreversible commitments are dangerous. It breaks when each stage becomes a separately priced revenue event, the production bridge is neither contractually nor operationally owned, and "pilot" becomes a sink for budget rather than a bridge to deployment.

The "AI strategy" engagement model is carried by Accenture, Bain, PwC, and McKinsey's strategy practice. Accenture's Reinventing Enterprise Models in the Age of Generative AI is one of the cleaner public statements of the model: AI is not a tooling choice but an operating-model shift, so leadership must align portfolio bets, governance, architecture, and workforce strategy before scaling execution (Accenture, 2024). It is correct for board-level prioritisation and portfolio rationalisation. It breaks in mid-market firms because strategy work without a shipped system creates the appearance of progress while leaving the actual integration, evaluation, and adoption burden untouched. The strategy deck becomes the deliverable; the production system becomes the unspoken next phase.

The vibe coding and agentic-development narrative is the newest of the four. It is carried by Andrej Karpathy's "vibe coding" framing, by Replit Agent, by Cursor, and by the Claude Code product narrative. Its claim is that model-assisted coding has compressed software creation time and broadened who can build, moving engineering leverage from typing to intent, orchestration, and review. It is materially true for greenfield experiments, UI scaffolds, and bounded implementation tasks. It breaks where it matters most for production: a controlled trial published by METR in July 2025 found that experienced open-source developers working in mature codebases were 19% slower with frontier AI coding tools than without them (METR, 2025). The cost of building a demo has collapsed; the cost of operating a production system in a mature codebase has not.

These four paradigms are not equally wrong. They are correctly aimed at different segments and contexts. What they share, when they reach the mid-market industrial buyer, is a common failure mode: they produce vendor engagements that are paid before the production system is committed.

What works instead

The mechanism the cluster describes is not novel. It is the engineering engagement model that built the production internet — and that the consulting register stopped writing about a decade ago because the model does not scale the way analyst-class revenue scales.

The structural move is to bind the vendor's revenue to the operational artifact. The discovery phase is paid as engineering work — not as a discovery product — with a working prototype on the buyer's real data as the contractual deliverable. The build phase is fixed in scope and price, built by the same engineers who ran the discovery. The operate phase is a separately priced retainer that the buyer chooses, in which the engineering team that built the system carries the on-call rotation for the system it built. The three phases are commercially distinct but operationally continuous. The vendor is paid more for shipping more. The vendor is paid less for shipping less.

The named components of this engagement model are concrete. The Foundation Sprint is the paid discovery — two weeks, low-four-figures, ending with a working prototype. The Production Build is the next phase — defined scope, defined price, defined production deliverable. The Operate Partnership is the retainer — named on-call, contractual incident SLA, the same engineers as the build phase.

Why this configuration works where the consulting configuration breaks: because the same people who built the system are the people who answer the page when it breaks, the engineering decisions during build are made with five-year operational consequences in mind. Because the discovery output is a working prototype rather than a roadmap, the buyer's procurement decision is anchored in an artifact that is harder to descope than a document. Because the operate phase is chosen by the buyer rather than coerced, the vendor's incentive is to make the system maintainable — not to lock in a long-tail support contract whose value depends on the system being fragile.

A specific case that illustrates the configuration: in one current engagement with a mid-market industrial-equipment distributor, the buyer had been quoted by a previous vendor for a discovery-then-strategy engagement priced in the mid-five-figures. The buyer hesitated because their internal IT lead — the person who owns the ERP and would carry the operational consequences — read the proposal as engineering and saw that the production phase was a future conversation. The engagement we ran instead was structured as paid two-week sprints in the low-four-figures each, with the working prototype on the buyer's real catalogue data as the first deliverable. The proposal-anatomy walkthrough lives in vendor pricing predicts production outcome; the operational test the IT lead was reflexively running lives in the on-call question.

Why this configuration wins where the consulting configuration cannot

The configuration is not the only one rejecting the consulting register. There are at least three adjacent alternatives — pure SaaS, internal builds, and offshore engineering shops — that also reject the consulting engagement model. The engineering-shop configuration the cluster describes wins specifically against these by occupying a position none of them can.

SaaS cannot reach the mid-market industrial buyer's actual operational reality. The ERP is hand-tuned. The catalogues are domain-specific. The compliance posture is national. The off-the-shelf product is generic by construction. The mid-market buyer that has tried a horizontal SaaS for AI inventory or AI quoting has watched it underperform on their own data and concluded — incorrectly — that AI does not work for their situation.

Internal builds cannot reach the production phase in mid-market companies because the internal AI team, if it exists at all, is one to three engineers with full-time obligations elsewhere. Eurostat reports that only 20% of EU enterprises with ten or more employees used AI in 2025, with Poland at 8.4% — and internal-build AI is a small fraction of that (Eurostat, 2025). The internal team is the right partner during the build, not the right delivery vehicle for the build itself.

Offshore engineering shops can deliver code, but they cannot bind to production outcome at the operating-model level. The cost structure does not support an on-call rotation in the buyer's timezone with the same engineers across phases. The engagement model has not absorbed the operational discipline that mid-market production AI requires.

The engineering-shop configuration — paid discovery with a working prototype, fixed-scope build, optional operate retainer — is the only one that can plausibly bind the same five-engineer team to the same buyer's system from prototype through year five. That is the structural advantage. It is not a credential argument. It is a configuration argument.

The objections that miss the point

There are three reliable objections to this article's argument. Each one is worth addressing directly.

The first objection: the academic literature on fixed-price contracts shows higher failure rates than time-and-materials, so your argument is wrong about pricing structures. The objection is rooted in real research — Jørgensen et al. 2017 documents this in outsourced IT projects. The answer is that the cluster's argument is not about fixed-price versus time-and-materials abstractly. It is about discovery-as-product versus shipped-system-as-product. The variable is what the contract commits the vendor to ship, not how the work is priced inside the engagement. A fixed-price discovery engagement and a T&M discovery engagement both produce documents; a fixed-price engineering engagement and a T&M engineering engagement both produce systems. The pricing-form question is a layer below the structural question.

The second objection: the consulting maturity framing has decades of evidence behind it; the production gap is real and is partly a buyer problem. The answer is yes, partly. Mid-market buyers do have organisational gaps. The argument is not that buyer-side variables are zero; it is that they are additive to the vendor-side variable, not exclusive of it. The maturity framing treats the vendor side as constant and the buyer side as the explanatory variable. The cluster's argument is that the vendor side is the explanatory variable that the maturity framing is structurally unable to measure. Both can be true. The maturity framing measures one of them. The pricing diagnosis measures the other.

The third objection: foundation models have changed the production gap by making demos cheaper, so the argument is dated. The answer is the opposite. The Chip Huyen analysis of AI engineering pitfalls describes a team that reached 80% of the desired user experience in one month and then needed four more months to reach the remaining 15% (Huyen, 2025). The gap between demo speed and production speed has widened, not narrowed, since foundation models became commercially available. The cluster's diagnosis is more applicable now than it was three years ago, not less.

The shift in plain terms

The shift this article is describing is this: mid-market AI POCs fail not because buyers aren't ready, but because vendors are paid for discovery, not for operating the system that actually ships.

This is not an incremental improvement to the consulting register. It is a reframing of where the production gap lives. Once you see that the vendor's incentive structure decides what artifact gets delivered, the question stops being how mature is our organisation. It becomes what is this vendor paid to commit to, and what is the artifact they will ship. The first question produces years of readiness assessments. The second one produces a working prototype in two weeks and a production system in two to three months.

What changes from Monday morning

Here is what the cluster's argument implies for any AI buyer evaluating their next vendor engagement.

First, read every AI vendor proposal as an engineering document, not as a procurement document. Search the proposal for the phrase working prototype on real data and the phrase production deployment. If neither appears in the contractual deliverable list for the first phase, the proposal is selling discovery. If both appear, the proposal is selling engineering. The CFO's question is what is the line-item cost. The engineering owner's question is what do I own at the end of phase one. Both questions are legitimate. Only the second one predicts the production outcome.

Second, ask the on-call question explicitly in vendor discovery: who, by name, will be on call for this system at three in the morning on a Saturday after the build phase ends. If the vendor cannot answer, the engagement is not ready to sign. If the vendor can answer, ask for the named individuals to be written into the contract. The on-call rotation is the single most predictive engineering artifact for production survival, and it is the one consulting engagements systematically omit.

Third, evaluate the vendor on data engineering depth, not on ML credentials. The interesting engineering work in an AI project is almost never the model. It is the data pipeline, the failure modes, and the integration with the system of record. The team that takes this seriously enough to staff for it is the team that ships into production.

Stop buying maturity assessments. Stop buying strategy roadmaps as standalone deliverables. Stop signing engagements whose first-phase deliverable is a document.

What this means for the next AI engagement on your desk

The reframing matters most at the moment of the next signature. The maturity diagnosis has produced a generation of buyers who interpret a stalled AI initiative as their own organisational failing — and who buy another readiness engagement to fix it. The diagnosis this article offers is different. The stalled initiative was a vendor incentive problem; the next engagement should be evaluated as one too.

In practice, that means reading the proposal as an engineering document. Searching for the words working prototype on real data and production deployment in the contractual deliverable list. Asking who, by name, will be on call after the build phase ends. Evaluating the vendor on data engineering depth rather than on ML credentials. Treating the pricing structure as the engineering decision it is. None of these moves are exotic. All of them are systematically absent from the consulting register because the consulting register was built to sell a different artifact.

If the engagement model this article describes is the one that fits the AI initiative on your desk, the Foundation Sprint is the entry point: two weeks, a working prototype on your real data, a decision-grade roadmap as the by-product. Worth doing carefully.