# How to scope an AI pilot so it can actually reach production

_Most AI pilots are lost in the week before anyone writes code, when nobody agreed what the pilot was for. Scoping is the cheapest place to fix that._

A practitioner's guide to scoping an AI pilot for production, not for a demo. Agree on success first, pick the use case for impact, and run build-vs-buy against a real cost model, with an anonymized story from an enterprise AI leader.

# How to scope an AI pilot so it can actually reach production

Most AI pilots are lost before the first line of code, in the week when nobody agreed what the pilot was for. A pilot scoped without production in mind produces a demo, a debate about whether it worked, and no path forward. Scoping is where pilots are won or lost, and it is the cheapest stage to get right.

## Agree on success before you start, not after

The most common scoping failure is starting without success criteria everyone signed off on. Skip that step and the pilot has no finish line. Stakeholders disagree about whether it worked, and the decision to go to production turns political instead of factual. Whoever argues hardest wins, which is not the same as the pilot being right.

So write the criteria down first. What number has to move, by how much, measured how, for this to be worth building. Commit to it before you see results, because criteria set after the fact are just a story you tell about numbers you already have.

## Pick the use case for impact, not for how interesting it is

The most technically interesting problem is almost never the right place to start. Pick the first use case on three things: business impact if it works, whether the data for it is actually ready, and whether the team around it will adopt it. Teams that choose this way build momentum. Teams that chase the hardest problem first build frustration and a stalled pilot.

A CEO who spent two decades running digital and AI programs inside a large services firm, before founding an AI-native engineering company, put it to me plainly. When a client asks for a "transformation," the first thing he checks is whether the goal ties to an outcome worth the effort. One client he described was chasing a plan where the change would pull revenue forward by five quarters. That is a north star a whole company can line up behind. His sharpest line was that contextualization, teaching the system your specific business, is the difference between a demo and a deployed solution. A pilot scoped as a generic capability stays a demo. A pilot scoped around one real outcome has somewhere to go.

## Build vs buy: answer it with a framework, before you commit

The expensive mistake is not picking the wrong path. It is picking without a framework and discovering the cost twelve months into a program you already committed to. Two facts should anchor the decision.

First, about 70% of enterprise AI use cases are served well enough by an existing off-the-shelf tool (McKinsey, 2025). Over-engineering a custom build for a problem a platform already solves is a common way to burn a budget. Second, when you do build, the pilots that reach production are far more often partnerships than solo internal builds. MIT found vendor-partnership pilots reached production about twice as often as building alone, mostly because an outside partner carries accountability that keeps the work moving past the demo.

Before any significant build, put a three-year total-cost model on paper: development, maintenance, infrastructure, compliance, headcount, and the opportunity cost of the engineers you pull off other work. Most build-vs-buy regret comes from comparing build cost to license cost and forgetting the other five lines.

## How we approach it at Density Labs

Scoping is the core of our AI Opportunity Assessment, a $2,500 engagement. Before anyone builds, we pin down the success criteria, pick the use case on impact and data readiness rather than novelty, run the build-vs-buy decision against a real total-cost model, and hand you a prioritized path to production. Often the most valuable output is a clear "buy this, do not build it," which saves you a custom project that was never going to pay off.

If your last pilot ended in an argument about whether it worked, the fix is not a better model. It is a tighter scope, agreed up front, aimed at a use case chosen for impact instead of interest.