Prototype to production
A first version exists and it works. Built fast, in house, by an agency or with AI tools, it did its job: demonstrating, convincing, sometimes already serving users. This is not about starting over, it is about making it hold up over time, in front of real users.
When to call us
- _Your prototype has convinced people and now has to be opened to real users.
- _A first version built with AI tools works, and no one can say whether it will hold.
- _A client or a pilot forces a real move to production, with the commitments that come with it.
- _Your team is torn between stabilising what exists and rewriting, and wants to decide on evidence.
- _New constraints appear: security, personal data, compliance, several clients to keep apart.
What changes when a prototype becomes a product
A prototype is judged on what it shows. A product is judged on what it keeps doing over time: when the data piles up, when two clients must not see the same things, when something fails at night.
None of this is a failing of the prototype: it was outside its scope, and that is what let it move fast. The difficulty is not only technical, it is deciding what genuinely deserves to be reworked.
What we secure
Data and access: what is stored, where, who can read it, and what you will need to prove when a client asks.
Infrastructure and its cost, which a prototype architecture often bills per request. Then operations: knowing something failed before the user writes in to say so.
And whether the product can be picked up: the least spectacular question and the most decisive one. Can a team other than the one that wrote it keep this product moving in six months?
Stabilise before rewriting
What works stays, until proven otherwise. A full rewrite costs months, recreates behaviour your first users have already validated, and swaps known risks for its own.
It is sometimes the right decision. It is then demonstrated part by part, and usually covers one specific component rather than the whole product.
How we work
We start from the use that has to work in production, not from an exhaustive clean-up of the code: a prototype always contains parts no one will ever use.
One team arbitrates product, design, frontend, backend, data and infrastructure. On a move to production, those decisions are not taken separately.
We commit to what the version must make it possible to operate in production, within the agreed time and budget. Arbitrating the work needed to get there is our job, with you.
What you get
- _What can stay, what has to change, and the stabilise-or-rewrite call for each part
- _The product in production: data, access, security, deployment, observability
- _Documentation allowing another team to take the product over
- _The path for what comes next: what is left to address, and in what order
Frequently asked questions
Does everything have to be rewritten to go to production?
Usually not. Part of the prototype already holds up, and replacing it would cost time without returning anything. The call is made part by part, and you validate it. If your need stops at that diagnosis, it is the technology audit.
Do you work on code generated by AI tools?
Yes. Whether code was generated or written by hand says nothing about its quality on its own: what matters is what it does, what it exposes, and what it will cost to change.
How long does a move to production take?
It depends on what the prototype left aside. We start by establishing that: this first step ends with a costed arbitration.
How we frame, arbitrate and commit is set out in detail in the Vezero Method.