The strongest strategic frame in the forward deployed engineer literature belongs to the vendors. Services-led AI companies, the argument runs, deliberately trade gross margin early, embedding engineers with customers, and mine those engagements for the patterns that become platform. The deployments are the moat's quarry. It is a good argument, and it is entirely one-sided: the compounding it describes accrues to the company selling the deployment.
Flip the frame to the company buying, and the same geometry appears with the opposite ending. Every engagement embeds deep knowledge of the buyer's operations into someone's head and someone's codebase. If the conversion runs vendorward, the buyer has paid to deepen someone else's moat with its own material. If the conversion runs homeward, each engagement deposits connectors, evaluation harnesses, data pipelines, playbooks, and hard-won defaults, and the buyer's second deployment costs half the first.
Same math. The only variable is the direction of the conversion. That direction is a decision, and most companies never make it.
The conversion rate is the strategy
Define it plainly: deployment conversion is the share of engagement N that becomes engagement N+1's starting position. The extracted integrations, the reusable harness, the documented exceptions, the eval suite, the on-call runbook. Everything a future deployment would otherwise rebuild from zero.
The number is diagnostic. High conversion, and the company is running a compounding loop: each vendor engagement, each internal build, each automation project raises the floor of the next one, which is Ten Years Is Not Ten Years of Experience at organizational scale, the conversion rate of wins into repeatable systems rather than the count of years survived. Low conversion, and the company is running a subscription to its own evolution: work arrives, value ships, nothing deposits, and the fifth deployment costs what the first did.
The failure has a signature. Ask a company on its fourth AI deployment what the second one reused from the first, and watch the answer assemble itself from memory rather than from an artifact. There is no inventory, because nobody was assigned to build one, because the engagement was scoped as a delivery rather than as a mine. The vendor scoped it that way correctly, from the vendor's side. The buyer agreeing to that scope unmodified is the strategic error, and it is made quietly, in a statement of work, years before the cost is visible.
Why vendors convert and buyers don't
The asymmetry is structural, not intellectual. Vendors convert because their business model prices the conversion: the pattern extracted from customer A is revenue from customer B, so the extraction has an owner, a pipeline, and a review. Buyers don't convert because the extraction has no revenue line. Nothing in the buyer's accounting credits the connector that would halve the next engagement. The artifact that compounds is, from the project's point of view, scope creep.
This is the exact mechanism of From MVP to MVP Loops: Testing Ventures Continuously, transposed: a loop only compounds if the test produces a retained conclusion, and most deployment projects are run as one-shot tests whose learnings evaporate on contact with the next sprint. The venture version of the fix is the thesis doc and the readout. The deployment version is the extraction step, and it needs three things to exist:
- A standing inventory. One place where connectors, harnesses, eval suites, prompts that survived production, and exception playbooks accumulate, owned, versioned, and boring.
- An extraction moment per engagement. The last week of any deployment includes, as a deliverable, mining the engagement: what here is reusable, written down, moved into the inventory. Non-optional, in the statement of work, for vendor engagements as much as internal ones.
- A conversion review. Quarterly, one question with numbers: what did this quarter's work deposit, and what did we rebuild that we already had? Rebuilding existing capability is the receipt for a broken loop.
The economics compound faster than intuition suggests, because deployment work has a fat reusable core. The authentication wrapper, the data extract, the evaluation harness, the escalation routes, the compliance checks: the first engagement builds them under pressure, and every later engagement in that domain needs them again. A company three deployments deep, converting at even half its surface, is operating with infrastructure no vendor can sell it, because it is specific to its own operations. That specificity is the point. AI-Native Products Should Sell Completed Outcomes, Not Feature Access makes the market-side case for outcomes; this is the asset-side case for the buyer: the completed outcome you want to own is your own growing base of deployment capital.
What this is not
Not an argument against buying deployments or hiring vendors. Early engagements should often be vendor-led: the expertise is real, the speed is real, and pretending every company should build everything internally is the other classic error. The claim is about the terms and the extraction, not the source. Vendor-led with a conversion clause beats internal-only with no inventory.
Not a claim that everything extracts. Some share of every engagement is genuinely specific, one customer, one window, one mess. The conversion discipline is honest about the split: reusable things go to the inventory, specific things go to the map of the operation, and nothing pretends to be the other kind.
And not a portfolio argument for building internal platform prematurely. The inventory earns its keep from engagement two onward; before that, it is ceremony. Convert what exists, when it exists, and let the platform declare itself after the third deposit rather than before the first.
Take-home
- Add one line to the next statement of work: the final week includes extracting everything reusable into the company's inventory. Vendors will accept it; it costs them a week and keeps the relationship honest.
- Check whether engagement four rebuilt anything engagement three already built. If yes, the loop is broken at the extraction step, and no amount of tool spend fixes a missing deliverable.
- Treat the inventory as deployment capital, reviewed quarterly. The company's real AI maturity is not how many deployments it has bought. It is how much of them it still owns.
Related reading:
- Ten Years Is Not Ten Years of Experience
- From MVP to MVP Loops: Testing Ventures Continuously
- The Deployment Teaches the Company What It Is
- AI-Native Products Should Sell Completed Outcomes, Not Feature Access
- Venture Building Runs on Loops of Experts
- The FDE Sits Where the Org Chart Has a Hole
If your deployments keep arriving at full price and departing at full speed, the compounding is running somewhere, just not for you. If you want help installing the extraction step and the conversion review, book a discovery call.
FAQ
What is deployment conversion?
The share of engagement N that becomes engagement N+1's starting position: connectors, evaluation harnesses, data pipelines, prompts that survived production, and exception playbooks. High conversion means each deployment raises the floor of the next. Low conversion means the fifth deployment costs what the first did, which is a subscription to your own evolution.
Why do vendors productize engagements but buyers don't?
Because the vendor's business model prices the extraction: a pattern pulled from one customer is revenue from the next, so it has an owner and a pipeline. On the buyer's side, the reusable artifact has no revenue line, so it reads as scope creep and never gets built. Fixing this is a terms problem, not a talent problem.
How does a company start converting deployments?
Three moves: a standing inventory for reusable deployment assets, an extraction week written into every statement of work as a deliverable, and a quarterly conversion review asking what the recent work deposited and what was rebuilt unnecessarily. Convert what exists, when it exists, and let internal platform emerge after the third deposit.
Should companies build everything internally instead of hiring vendors?
No. Early engagements should often be vendor-led, for the expertise and the speed. The strategic error is not buying deployments; it is buying them without extraction terms, so the compounding from your own operations accrues to the vendor's platform. Vendor-led with a conversion clause beats internal-only with no inventory.