Your prototype works. You showed it, people said yes, and the question becomes: when do we open it to everyone? This is the moment when the gap between a successful demonstration and a usable product becomes visible.
A prototype has one purpose, proving an idea holds. It achieves that by setting aside everything that does not serve the demonstration. Those set-aside items are precisely the work of going to production.
What a prototype always leaves out
Users who do unexpected things. During the demo you enter the right values in the right order. In production someone pastes an email address with a space in it, submits twice, hits back in the middle of a payment, or enters a date of birth in 1823. Every screen has to withstand that.
Real access rights. A prototype is shown with a single account. As soon as there are two customers, the question becomes: can the first see the second’s data? That defect is the leading application risk according to the OWASP ranking, and generated applications reproduce it almost every time.
Volume. A thirty-row list appears instantly. The same list with three thousand rows, loaded in full then sorted in the browser, takes a minute. The recommended threshold for the largest element on a page to appear is 2.5 seconds, and a prototype clears it easily while the database is empty.
What happens when something fails. An outside service does not answer, a payment is declined, an email never went out. The prototype plans for none of it because nothing failed during the demo.
The record. When a customer insists they placed an order and nothing shows, you need to be able to check. With no activity log, the discussion comes down to one word against another.
One underlying flaw that weighs more than the rest
Generation tools produce code that works, and that repeats itself. A GitClear study covering more than 200 million changed lines between 2020 and 2024 shows the share of copy-pasted lines rising from 8.3% to 12.3% over the period, while the share of moved lines, the signature of refactoring, fell from 24.1% to 9.5%.
In concrete terms: the same calculation rule ends up written in five different places. The day your discount rate changes, all five have to be found. One is always missed, and it is the one that touches invoicing.
This flaw causes no incident in the first month. It simply makes each change more expensive than the last, until nobody dares touch certain parts.
What to settle before committing to a date
How many users, and which ones. Opening to twenty people you know and to two thousand strangers are not the same job. A staged opening remains the cheapest way to learn.
Which data is sensitive. Business contact details are not handled like health records or identity documents. The level of rigour, and the legal duties, follow directly.
What must never break. In any application, two or three journeys really matter: signing up, paying, receiving confirmation. Those are the ones protected by automatic checks, not the entire codebase.
Who answers when a user writes in. Going live with nobody at the other end turns the smallest incident into silence, then into a bad review.
The order to work in
The sequence that works always starts with access rights and exposed secrets, because those are the only defects whose consequences cannot be undone. Data that has leaked cannot be recalled.
Then comes the robustness of the essential journeys, then behaviour under a realistic volume, and finally the reworking of code that is expensive to change.
That last point is not always required before opening. It becomes so as soon as you expect several months of successive changes.
The cost of waiting
Putting this work off carries a price that does not show up immediately.
Every week spent adding features on a fragile base increases the amount of code to rework later. A rule duplicated across three screens becomes a rule duplicated across eight. The refactoring that took two days takes six.
On security the arithmetic is different and harsher. An application opened with broken access rights exposes its data from day one, and data that has left does not come back. Where personal information is involved, discovering the leak opens a 72-hour window to notify the French data protection authority, a procedure set out on its site, and that window starts when you become aware of it.
So the calculation splits in two. What is reversible can wait and be handled as you go. What is not gets handled before opening, even if that moves the date by a few weeks.
What your first users decide for you
Going into production is not a switch, it is a progression that gets organised.
Opening to a handful of internal users for a week, on real data, reveals what no internal check produces: the uses nobody thought of. A salesperson entering thirty orders in a row finds three irritations in one morning that you would never have seen.
Then comes a small group of customers told they are first in. That transparency changes everything: a warned user reports a problem, a surprised user leaves.
At each step, one question: what broke, and what does that reveal about the rest? A defect found on one screen usually exists on every screen built the same way.
This progression does not lengthen the schedule, it moves what fills it. Time spent opening gradually is time not spent repairing under pressure with unhappy customers.
What we do
We take your prototype and set out the gap between its current state and what a real opening assumes, in plain language, point by point, with what each one represents.
You choose what gets handled before opening and what can wait. Each batch is quoted separately, at a fixed price, and delivered so that you can see progress.
We do not take over your hosting and we do not operate your application. We hand you back a product you can open without dreading the first Monday.