Taking an internal prototype to production safely

A colleague built a tool with Lovable, Bolt, Bubble or a souped-up spreadsheet. The team adopts it, usage grows, and one day someone suggests putting the real customers, the real prices, the real HR data into it. That is the moment a prototype becomes a production tool, and the risks change in nature. Here are the checks to run before that step, the order I tackle them in, and what it costs.

Prototype vs production: what really changes

A prototype answers one question: “does the idea work?” A production tool has to answer others: what happens if a user makes a mistake, if someone tries to see what they should not, if the server goes down, if the person who built it leaves?

The ten checks before going to production

This is the list I use in every prototype audit. It complements the checklist in the guide on building an app yourself with AI.

1. Access rules enforced on the server: each user only sees and changes what they should, even when calling the API directly.
2. No secret keys in the code sent to the browser or in the repository history.
3. Named accounts, no shared logins, and two-factor authentication for administrators.
4. Automatic backups of the database and files, with a restore that has already been tested.
5. Two environments: one for testing, one for working.
6. Code in a Git repository owned by the company.
7. Technical accounts tied to the company: database, hosting, domain, third-party services, with at least two administrators.
8. Personal data handled properly: record of processing, retention periods, known hosting location.
9. A log of sensitive actions: who changed a price, deleted a record, exported data.
10. Someone able to take over: minimal documentation, readable code.

Below eight out of ten, I advise against putting real data into the tool.

The order to fix the gaps

Not everything happens at once. My priorities follow the level of risk:

1. First, whatever could leak or lose data: access rules, exposed keys, backups. See the page on backups and disaster recovery.
2. Next, whatever protects the company from dependence: account ownership, code repository, documentation.
3. Then, whatever makes changes safe: test environment, tests on critical flows.
4. Finally, comfort: performance, polish, new features.

If the audit shows the foundation is too fragile to fix, rebuilding becomes the most economical option. The prototype keeps all its value: it becomes the requirements.

What going to production costs

For an estimate that takes your prototype into account, use the estimator. After go-live, plan for hosting (a few tens to a few hundred euros a year) and maintenance; three months of support are included in my projects.

When you do not need all this

I will be straightforward: a tool used by two people, on non-sensitive data, that could be rebuilt in a day if it disappeared, does not need this full process. Regular backups and accounts tied to the company are enough. Likewise, if an off-the-shelf product already does 90% of what your prototype does, it may be wiser to adopt it and keep the prototype for what is missing.

Where to start

1. Take stock of the access and check that it belongs to the company.
2. Back everything up right away: code, database and files, before any further change.
3. Go through the checklist above honestly, with the person who built the tool.
4. Ask for an audit through my AI project takeover offer: you get an assessment and a costed action plan, then decide between an upgrade, a rebuild or ongoing support.