Vendor pricing predicts production outcome — the engineering decision treated as procurement
Consulting engagements paid for discovery are structurally worse than engineering engagements paid for shipped systems, regardless of credentials. Here is the proposal anatomy that reveals it.
We started one of our recent engagements — a multi-module platform build for a mid-market industrial-equipment distributor in Poland — in a conversation that took place because the buyer had been burned. The previous year, a different vendor had proposed a roughly five-figure engagement, in the mid-five-figures region, for what was described as a discovery-and-strategy phase that would produce a roadmap for an AI-enabled quote and inventory system. The buyer had agreed verbally. They had not signed. Something in the proposal felt wrong, but they could not articulate what.
When the proposal landed on our desk for a second opinion, what was wrong was visible in two minutes. The discovery phase had a fixed price. The build phase did not. The build phase was described as "subject to scoping after discovery". There was no working prototype committed to the discovery deliverable. There was no production system committed anywhere in the proposal. The vendor was selling a document — a roadmap — and the rest of the engagement was a budget for conversations that might or might not happen.
The buyer had been right to hesitate. What they had been looking at was not a software engineering proposal. It was a discovery contract dressed in production language.
What we proposed instead
Our proposal was structurally different in a way the buyer initially read as smaller. We offered a two-week paid Foundation Sprint, priced in the low-four-figures, with a working prototype on the buyer's real catalogue data as the contractual deliverable. The Sprint would end with a decision-grade roadmap — yes — but the roadmap would be the by-product of having built the first working version of the system, not the primary thing the buyer was paying for. The Production Build phase had a fixed scope for the first module, with a defined price, with the working prototype from the Sprint as the input. If the Sprint did not produce a usable prototype, the engagement would not proceed and the Sprint cost would not be charged.
The buyer asked why our discovery was so much cheaper. The honest answer was that we were not charging for discovery as a product. We were charging for the engineering work of building the first version, and the discovery was the activity that engineering required us to do. The roadmap was a free output of that work. The other vendor had been charging for the roadmap as the deliverable, with the engineering described as a separate future engagement that might never be commissioned.
A useful way to read any AI vendor proposal: search for the phrase working prototype on real data and the phrase production deployment, and check whether either is contractually committed inside the first phase. If neither is, the proposal is selling discovery. If both are, the proposal is selling engineering.
Where it broke for the other vendor
The reason the previous proposal had failed to close — even though the buyer had verbally agreed — was that the buyer's internal IT lead had read it carefully and had pushed back. He was the person who owned the ERP integration. He was the person who would be on call when the AI system started producing wrong outputs. He understood, from a fifteen-year career operating production systems, that a discovery contract without a committed production phase was a budget for a document, not for a system. He could not name his objection in those terms, but he knew enough to delay signing.
This is a pattern we have seen across the engagements we have been called in to rescue or review. The technical decision-maker on the buyer's side — the CTO, the VP of Engineering, the internal IT lead — almost always reads the pricing structure as an engineering signal, even if the procurement process treats it as a procurement detail. The CFO sees a number. The CEO sees a vendor reputation. The engineering owner sees the implicit incentives in how the work is staged and paid for, and they react to those incentives even when they cannot articulate why.
The buyer in this engagement — a family-run mid-market company where the father was the financial decision-maker and the son was the internal champion — had been about to override the IT lead's hesitation. Three weeks later, they were in our discovery instead. The IT lead's instinct was the same one the on-call question draws out structurally — he was reading the proposal as the person who would carry the operational consequences, not as the person who would countersign the invoice.
What changed in the engagement model
The work between the two proposals was not technical depth. Both vendors could have built the system. The difference was structural: one was being paid to advise, the other was being paid to ship.
In our engagement model, the Foundation Sprint produces a working artifact in two weeks. The Production Build delivers a deployed system in roughly two to three months. The Operate Partnership is a separate retainer that the buyer can choose to engage or not — and crucially, the engineering team that built the system is the engineering team that operates it, with named individuals on call. The three phases are contractually distinct but operationally continuous: the same people, the same code, the same understanding of the customer's domain, from prototype through five-year operation.
In the consulting engagement model — the one the buyer almost signed — the three phases are commercial events that are sold separately and may or may not be staffed by the same people. The discovery phase is the most profitable per hour. The build phase is staffed by a different team than the one that ran the discovery. The operate phase, if it exists at all, is structured as a long-tail support arrangement with no named on-call engineer. Each phase has its own scope-of-work document, its own pricing, and its own opportunity for the vendor to descope the production deliverable. The engineering ownership is broken across the phases, and the system that gets delivered at the end is the system that survived four scope-reduction conversations.
This is the structural argument the cluster anchors on. The variable that matters is not fixed-price versus time-and-materials. It is whether the vendor's incentive is aligned with shipping a system that runs, or with advising a process that produces documents. A vendor paid for discovery will produce more discovery. A vendor paid for shipped systems will produce more shipped systems. The pricing model is the engineering decision, not the procurement detail.
What stuck across the engagements since
A working demo is the cheapest part of an AI system. The rest of the cost — the integration with the customer's data, the data engineering layer, the evaluation harness, the on-call story, the documentation, the operate phase — is the part that pricing structure decides whether the vendor is staffed to deliver. We have seen this pattern across the engagements we have run or rescued: the proposal that prices discovery as the product produces an engagement that delivers a discovery document. The proposal that prices the working prototype as the deliverable produces an engagement that delivers a working prototype. The pricing model predicts the artifact.
This is moving from a niche position into a more general industry direction. Gartner's framing of "Outcome as Agentic Solution" — value shifting from access to guaranteed execution — describes the same incentive realignment we describe here, from the analyst side (Gartner via ITPro, 2026). The mid-market AI engagement model is moving toward accountability-linked commercial structures, and the consulting register that priced discovery as the product is moving away from the procurement reality of mid-market industrial buyers who have been burned and learned.
The honest admission is that this is also the engagement model that has cost us deals. The discovery-priced proposal is what most CFOs are trained to evaluate against — a fixed line item in a procurement system that does not have a column for "and at the end of this you will own a working system." We have had buyers who chose the higher-priced consulting proposal because the budget structure inside their company could not accommodate ours. In those cases, we said so plainly and moved on. The cluster's argument is not that this engagement model wins every deal. It is that the engagement model is visible in the proposal, and the buyer who reads the proposal as an engineering document — not as a procurement document — sees the production outcome before they sign.
What to look for in the next proposal you read
A proposal that prices an AI engagement as discovery — and treats the production system as a downstream conversation — has a recognisable anatomy. The first phase is priced at twenty to forty percent of the projected total engagement value. The first phase deliverable is a document, not a system. The second phase scope is described as "subject to scoping after discovery". The production deployment is mentioned in the timeline but not in the contractual deliverable list. The operate phase, if mentioned, is described as best-effort support rather than as a named on-call rotation with an SLA. The team named in the proposal for the discovery phase is different from the team named for the build phase, or the build-phase team is unnamed.
A proposal that prices the engagement as engineering looks different. The first phase is priced for the work of building the first version, with the working prototype as the contractual deliverable. The build phase has a defined scope, a defined price, and the same engineers who ran the first phase. The operate phase is a separately priced retainer that the buyer can engage on completion of the build, with named on-call rotation and a contractual incident SLA.
The two proposals can look similar on the cover page. The first column of the first phase is roughly comparable in price. The difference becomes visible when the buyer reads what is actually being committed in each phase, and asks the question: at the end of phase one, what do I own? If the answer is a document, the proposal is selling discovery. If the answer is a working system on my real data, the proposal is selling engineering.
The six discovery tells from this section as a checklist — enable JavaScript to run it.
What to ask before the proposal is signed
A buyer who reads the proposal as an engineering document, not a procurement document, has one question that does the heaviest filtering: at the end of phase one, what do I own? If the answer is a document, the proposal is selling discovery. If the answer is a working system on my real data, the proposal is selling engineering.
The vendor's pricing model is the engineering decision the buyer keeps treating as a procurement detail. The variable that matters is not fixed-price versus time-and-materials. It is whether the vendor is paid to ship or paid to advise.
That distinction is the engagement-model decision. Worth making consciously.