From AI prototype to production: the whole path
Why AI prototypes die in production ends at a decision: run the keep-or-kill test, learn what deserves to survive. The question founders ask next is the practical one — fine, but what does "building the real thing" actually involve?
Here's the honest answer, stage by stage. Four of them, each existing to answer one question, each with an exit you can check. No mystery, no methodology brand names — this is just what has to happen, in the order it has to happen.
One reassurance first, because the fear is universal: promoting a prototype does not mean starting over. The prototype earned answers — about demand, about the workflow, about whether the AI feature works at all. You promote the answers. The code comes along only where it passes the test.
Stage 1 — Discovery & validation
The question: what must be true on day one?
A prototype with real users is discovery evidence, and good discovery starts by inventorying it honestly: what did it prove, and what did it merely demo? Demand is proof. A workflow people return to is proof. A polished screen is not.
Then the scope gets pressure-tested against the business — what the product must earn, who pays, what "working" means measurably — and the riskiest assumption still standing gets named. If that pressure changes the plan, that's discovery working, not failing.
You leave with: a day-one scope you can defend out loud, the keep list from your prototype, and the riskiest assumption written down. Sometimes you leave with "don't build this yet." That's the stage doing its job.
Stage 2 — Strategy & architecture
The question: what shape survives your business model?
Technical decisions made with the business model in the room: what to build versus what to buy, the stack, the data model, where the security boundaries sit. This is where the prototype's quiet debts get refused re-entry — the data model is designed for change instead of accumulated, tenancy and security become architecture instead of an audit response.
For the AI feature, this stage decides what the demo never asked: the evals that define "working," the budget that defines "affordable," the fallback that defines "resilient," and the seam that keeps the model swappable when it changes under you.
You leave with: a short written answer to what talks to what, who owns which data, and what happens when things fail. A page, not a tome — but a page that exists before the first prompt.
Stage 3 — Build & launch
The question: does the real thing hold?
The build is AI-accelerated — that's how a small studio moves fast — and the discipline around it is what makes the speed safe: architecture already decided, senior review of what ships, tests that encode intent from outside the generation loop.
Production readiness isn't a phase at the end; it's the first deploy. Migrations, CI, observability, secrets handled properly — from day one, because retrofitting any of them costs more than starting with them. The unhappy paths get built: empty states, partial failures, duplicate submissions, the malformed file, the user who is three users at once.
Launch is a gate, not a party. Strangers can use it like strangers. The slowest responses — the ones users actually feel — are measured. A serious customer's security questionnaire has answers.
You leave with: a product in production, holding.
Stage 4 — Scale & evolve
The question: what does traction demand next?
Real usage rewrites the roadmap — always. Now performance work has evidence instead of guesses, and the seams from stage 2 pay their rent: parts can change without archaeology, a new engineer can work behind one boundary without understanding all of them.
This stage doesn't end, and that's the point. Survival isn't a launch property; it's maintained. You leave with a product that gets easier to change as it grows, not harder — which is the entire difference between products that compound and prototypes that stall.
The promotion checklist
Twelve questions, four gates. If a gate's answers are solid, move.
Before architecture
- What did the prototype prove — and what did it only demo?
- Can you defend the day-one scope against "what must this earn"?
- Is the riskiest remaining assumption named, out loud, in writing?
Before the build
- Does a one-page answer exist for what talks to what, who owns which data, and what fails how?
- Could the data model change next month without fear?
- Does the AI feature have evals, a budget, and a fallback — decided, not intended?
Before launch
- Are the unhappy paths built, not just the demo path?
- Would a security questionnaire embarrass you?
- Can you deploy — and roll back — without a held breath?
- Do you know what the product costs to run per user?
After launch
- Are the slowest 5% of responses watched, and owned by someone?
- Has real usage revisited the roadmap — and named the next bottleneck?
What we won't tell you here
How long it takes, or what it costs. Not because it's a secret — because we'd be inventing it without having seen what your prototype already proved. The honest version of both numbers comes from a conversation, fast, after we've looked.
This path is Build, end to end. If your prototype just earned real users, the keep-or-kill test tells you where you stand — this is the road after it. Talk to us.