From AI-generated prototype to production software
A generated prototype gets you to a working demo in days. Production is a different set of guarantees, and they can be added in a deliberate order while the demo keeps earning its keep.
By Georgiy Gres · Founder & CEO August 2026 11 min read Something genuinely new happened in the last two years: a founder with a clear idea can now have a working, clickable, convincing product in a week. That prototype is a real asset. It has proved the concept, won the meeting and settled arguments that used to take months. The next question is what turns it into software that a paying customer relies on at nine on a Monday morning — and the answer is a known, orderable list.
We do a lot of this work, and the shape of it is consistent enough to write down. What follows is the list we work through, the order we work through it in, and what each stage is worth.
What the prototype already gives you
Start by counting the assets, because they are real and they shorten everything that follows.
- A settled product decision. The screens exist, the flow has been clicked through, and the arguments about what it should do have been had against something concrete. That is months of specification work already complete.
- A living specification. The prototype is the most accurate requirements document you will ever have, because it is executable.
- A stack that is usually mainstream. Generated projects tend to land on React, TypeScript, Node or Python and Postgres — exactly the ground senior engineers work on daily.
- Evidence. A demo that won a customer conversation has proved demand in a way a slide cannot.
None of that is discarded. In most of the engagements we take on, the majority of the prototype’s product surface survives into production.
The twelve areas production adds
Production is a set of guarantees about behaviour when things are busy, unusual, or unattended. Twelve areas cover nearly all of it.
| Area | What it guarantees | Typical effort |
|---|---|---|
| Authentication & authorisation | Every request is checked on the server, for the right user, at the right level | 1–2 weeks |
| Data model & migrations | The schema can change without downtime, and history is preserved | 1–3 weeks |
| Input validation | Every value entering the system is checked at the boundary | 3–7 days |
| Error handling | Unusual paths end in a defined state and a useful message | 1–2 weeks |
| Automated tests | A change can be made in month nine with confidence | 2–4 weeks |
| Secrets & configuration | Credentials live outside the code, per environment | 2–4 days |
| Deployment pipeline | Any change reaches production the same way, reversibly | 1–2 weeks |
| Observability | You learn about a problem before a customer tells you | 3–7 days |
| Backups & recovery | Data survives, and the restore has been rehearsed | 2–5 days |
| Performance under load | Behaviour at a thousand users is known, not assumed | 1–2 weeks |
| Cost control | Model and infrastructure spend is bounded and visible | 3–5 days |
| Documentation & handover | A second engineer can pick the system up | Continuous |
Added together for a prototype of moderate size, that is typically eight to sixteen weeks of senior work and $40,000 to $120,000. The range is wide because two things vary a lot: how much data has already accumulated in the prototype, and how regulated the domain is.
The parts specific to AI features
Where a product includes a model, four more areas join the list. They are the ones least often present in a first version, and the ones customers feel most directly.
Bounded behaviour
A model given a free hand produces a distribution of outputs. Production narrows it: structured output formats that are validated on arrival, a defined fallback for every call, and a maximum on retries. In our own work, the digital-employee product routes anything with a precise answer through ordinary deterministic code and secure database queries, and reserves the model for the part that genuinely needs language. That split is the single highest-value design decision in an AI feature.
Cost per interaction
Model spend scales with usage, and a design that is comfortable in a demo can be uncomfortable at a thousand conversations a day. Measuring cost per interaction early, then reducing it deliberately — shorter context, cached retrieval, a smaller model for the routine path — keeps the unit economics of the product intact.
Evaluation
A test suite for a model is a set of representative inputs with expected properties in the output, run on every change. It is what lets you upgrade a model or edit a prompt in month eight and know within minutes whether quality held.
Visible reasoning for support
When a customer reports an odd answer, someone has to be able to see what happened: the input, what was retrieved, what the model returned, and what the application did with it. Building that view early turns support from guesswork into a five-minute task.
A sequence that keeps the demo running
The instinct to start again is usually the expensive one. This order lets the prototype keep doing its job — winning customers, raising money — while the guarantees are added underneath it.
- Week one: a written assessment. Read the whole codebase, list what is present, name the highest-value gaps in order. Ours is a fixed-price audit and it produces a plan you own regardless of who executes it.
- Weeks one to two: safety first. Secrets moved out of the code, server-side authorisation on every route, input validation at the boundary, backups running. This is the shortest stage and the one that most changes how much you can afford to be relaxed about the rest.
- Weeks two to three: the pipeline. Environments, automated deployment, one-command rollback. Everything after this point moves faster because of it.
- Weeks three to six: the data model. The schema is the part that is genuinely costly to change later, so it comes before feature work and after safety. Migrations, constraints, indices, and a real backup restore rehearsed once.
- Weeks four to ten: tests around what matters. Not a coverage target — the paths that carry money, data and customer trust, plus the evaluation set if a model is involved.
- Weeks six to twelve: performance, observability, cost. Load behaviour measured, dashboards and alerts in place, spend per interaction bounded.
- Throughout: documentation. Written as the work happens, because written afterwards it is written twice.
Ship each stage to production as it is completed. A twelve-week hardening branch that lands in one release recreates exactly the uncertainty it set out to remove.
What this looks like when it goes well
The pattern repeats across engagements: the product surface survives, the foundation is replaced underneath it, and the team keeps shipping features throughout. Our largest published example of the underlying skill is a fourteen-year-old Go backend rewritten to Node.js in six months, against a conventional estimate of about two years — one senior engineer with AI leverage, every change specified, reviewed, security-checked and tested. The same discipline applied to a six-week-old prototype is a considerably smaller job.
Products we have taken from an early build to real scale include a social-media SaaS that reached mass adoption across web, native mobile and an AR experience, and a trading education platform serving over 8,000 monthly active users. In both, the production layer was added while the product was live.
How we use the same tools ourselves
We are not neutral about generated code, and it is worth being explicit about why. Our engineers use Claude Code every day, with a disciplined plugin stack around it: specification-driven development, review and security tooling, browser testing, and project memory. What makes it dependable is the process it sits inside. Every change is specified before it is written. Every change is reviewed by a senior engineer who reads the language. Every change runs through tests and security checks before it reaches a customer.
That combination is what lets us move at the speed the tooling allows while holding the standard that governments and banks require. It is also why we are comfortable taking on a generated prototype: we recognise what it is, we know exactly what it needs, and we are quick at supplying it.
Have a prototype you want to take further?
Thirty minutes with a senior engineer, a look at what you have, and a written view of what production would add and what it would cost. The assessment is yours to keep.
Questions people ask about this
Can an AI-generated prototype become production software, or is a rewrite needed?
In most cases it becomes production software. The product surface — screens, flows, data shapes — is usually sound and represents real decisions already made. What gets added underneath is authorisation, a durable data model, tests, a deployment pipeline, observability and documentation. A full rewrite is warranted mainly when the data model cannot support what the product now needs.
How long does hardening take?
For a prototype of moderate size, eight to sixteen weeks of senior work, with the highest-value items — secrets, authorisation, backups — landing in the first fortnight. The variables that move it most are how much production data has already accumulated and how regulated the domain is.
What does it cost?
Typically $40,000 to $120,000 for the full set of twelve areas. A fixed-price audit first, at a few thousand dollars, replaces that range with a specific number and a plan you keep whoever executes it.
Can we keep shipping features during the work?
Yes, and we recommend it. The sequence is designed so each stage reaches production as it is finished, which means the product keeps moving and the improvements are visible from the first fortnight.
Which parts should come first if the budget is limited?
Secrets out of the code, server-side authorisation on every route, input validation, and working backups. That is roughly two weeks and it covers the areas where an incident is both most likely and most costly.
Does Google or an enterprise buyer care whether code was AI-assisted?
Neither has any way of knowing, and neither is asking. What an enterprise buyer asks about is security review, test coverage, uptime history and support arrangements — questions about the process around the code rather than the tool that helped write it.
