The migration nobody planned: moving an AI feature off a prototype stack

An ops team at a healthcare startup proved out an AI feature in a notebook. It read records, called a model, and produced a summary a reviewer could trust. It worked well enough that leadership wanted it live, and that is where the trouble started. The notebook ran on one person’s laptop, against a personal model account, with data pulled by hand. None of that could go to production, and turning the demo into a shipped feature meant rebuilding most of it.

Nobody had planned for that. The plan was “the prototype works, now productionize it,” as if productionize were a small last step. It was not. The data access had to be rebuilt to run inside the company’s systems instead of a laptop. The personal model account had to move to a company account with real billing and scoped keys. The notebook logic had to become a service with error handling, logging, and a way to deploy it. The idea was proven. The thing that proved it could not ship, and the gap between the two was a project of its own.

The demo had quietly become load-bearing. Everyone was relying on it, so the real work looked like a rewrite of something that already worked, which is the hardest kind of work to fund.

Prototypes prove the idea, not the stack

A prototype answers one question: is this worth building. It is allowed to cut every corner to answer it. Personal accounts, hand-fed data, a notebook instead of a service, all fine, because the point is speed to an answer. The mistake is reading a yes from the prototype as a yes to its stack. Those are different questions. The prototype proved the idea has value. It proved nothing about whether the way it was built can carry production load, meet the company’s data rules, or be operated by anyone but its author.

The reason this bites is timing. By the time the prototype earns a yes, momentum wants the feature live now, and the migration off the prototype stack is invisible until someone tries to ship. Then the estimate that assumed a small final step meets a stack that has to be replaced, and the schedule slips in a way that reads as failure rather than the predictable cost it was.

What good teams do

Decide the target production stack before the prototype becomes something people depend on.
Keep the prototype honest about its status. Say plainly it is throwaway, so no one plans to ship it as-is.
Separate the two yes-or-no questions: is the idea worth it, and can this stack carry it. Answer them on purpose.
Budget the migration as its own work with its own estimate, not as a rounding error on the prototype.
Use production-shaped access to data and models early, even in the prototype, when that is cheap. It shrinks the later move.

How we approach it at Density Labs

Our AI Opportunity Assessment is a fixed two-week engagement at $2,500 that scopes real production work before you build. A recurring finding is a feature that “works” on a stack that cannot ship: a notebook, a no-code tool, a personal model account. We name the target stack, mark everything about the prototype that has to change to reach it, and put an estimate on that gap. That estimate is the number teams are missing when they say productionizing is nearly done.

The wider pattern holds here. Close to 95 percent of AI pilots stall on integration, not on the model, and a prototype stack that was never meant to ship is one of the plainest versions of that.

Let the prototype prove the idea and nothing else. Choose the stack you will actually ship on before the demo becomes the thing everyone is counting on.