What the sales deck left out of the scope

A VP of product at an edtech company told me about the demo that sold him and the six months that followed. The vendor showed an AI feature that graded open-ended student answers. It was clean. A student typed a response, the model scored it, the score was fair, the explanation was clear. Everyone in the room could see it. He bought the capability. Then his team started integrating it, and the gap between the demo and a feature students could actually use turned out to be the whole project.

Nothing in the demo was a lie. The problem was what the demo left out, and a demo is built to leave things out. It shows the happy path, the input the model handles well, the case that makes the point. The scope of a real feature is mostly the parts the deck skipped.

The demo is the smallest part of the work

He described what he now looks for, which is everything the demo did not show. There is a pattern to it, and it is roughly the same across vendors.

Integration. The demo ran on the vendor’s data in the vendor’s environment. Your feature runs on your data, in your systems, with your auth and your formats. That connection is real work the demo never touches.
Exceptions. The demo used a clean answer. Real students write blank responses, one-word responses, off-topic responses, responses in the wrong language, and responses that try to game the grader. Each of those is a case someone has to design a behavior for.
The messy real data. The demo answer was tidy. Your inputs have typos, missing context, formatting the model has never seen, and edge cases that only show up at volume.

He said the demo was maybe five percent of the eventual work, and it was the five percent that looked hardest and was actually easiest. The grading model mostly worked. What ate the six months was deciding what happens when a student submits nothing, how the score flows into the gradebook, who overrides a bad grade, and what the teacher sees when the model is unsure. None of that was in the deck, because none of that demos well.

Discovery is where you add back what the deck cut

His habit now is to treat any vendor demo as the beginning of scoping, not the end. The demo tells you the capability exists. Discovery tells you what surrounds it, and the surroundings are where the timeline and the budget actually live. He walks his team through the same questions after every impressive demo. What does this connect to on our side? What are the inputs that do not look like the one they showed us? What happens on the unhappy path? Who handles the case the model gets wrong?

A friend who leads engineering at a fintech told me she has a blunter version. She assumes the demo represents the part the vendor already solved, which means it represents the part she does not have to worry about. Her real scope is the inverse of the demo. Whatever they did not show is what she has to figure out. It is a useful inversion. The polish of a demo is a signal of where the work is not.

This is not a reason to distrust vendors. Off-the-shelf tools are often the right call. McKinsey found in 2025 that roughly 70 percent of enterprise AI use cases are adequately served by tools you can buy rather than build. The point is narrower. Even when the capability is bought, the scope of shipping it into your product is yours, and the demo is designed to make that scope look smaller than it is.

How we approach it at Density Labs

In the AI Opportunity Assessment, our two-week fixed engagement at $2,500, part of the work is reconstructing the scope a demo left out. We take the capability a vendor showed and map what it takes to make it real inside your product. The integration, the exception handling, the shape of your actual data, and the human steps around the model. That map is usually where the honest timeline lives, and it is far cheaper to draw before you have committed to a plan built on a happy path.

A demo shows you the capability. Discovery shows you the feature. Scope the difference before you sign, because the difference is the project.