From AI prototype to production: what actually has to change

The wall arrives on an ordinary day. Someone you showed the prototype to writes back and asks how to pay. Or their IT department writes instead, with a spreadsheet attached. Either way the question has changed, from “can you show me” to “where is my data”, “what happens if it goes down” and “who do I call”.

This is not the builder failing. The tool did what it was for: it turned an idea into something a stranger could click through, in an afternoon, for about the price of a lunch. That job is done. A different one starts now, and it has nothing to do with building. This guide is about what has to change before you let someone pay — and what to keep.

What “production” means, in one list

“Production” is not a feeling of being finished. It is a set of things that are either true of your application or not, and you can check each one this afternoon. They are written up in full in The cost of keeping software alive; here they are as a checklist to run against the app you have.

1. Uptime is watched from outside. Something that is not the application itself checks that it answers, on a short interval.
2. Errors reach a person. When the app fails in front of a user, a named person is told, with enough detail to reproduce it.
3. A restore was tested this month. Not a backup — a restore. Someone brought a backup up somewhere else and confirmed the data was all there.
4. There is a staging copy. A second copy with throwaway data, where a change can be tried before it touches the version customers use.
5. There is a rollback path. The previous version can be put back in minutes.
6. Dependencies were patched in the last 30 days. Every library the app depends on has been checked against published advisories and updated. Not scanned — updated.
7. Accounts have real permissions. Users belong to organisations, and roles decide what each one can see and change.
8. There is a written answer to “where is my data”. Country, region, who at your end can reach it, and how long it is kept.
9. There is a name on the incident. One person whose job it is when the application fails at two in the morning. If that name is yours, that is a valid answer, as long as it is a decision rather than a default.

Most prototypes score between zero and two, and that is not a criticism of the prototype. Nothing on this list is a building task. Several builders provide pieces — a daily database backup, an uptime check that emails the owner, a scan that lists findings — and the comparison pages record which. What no vendor documents is someone who holds the list for you.

Keep the brief, not the code

The prototype is the most valuable thing you have made. Its code is usually not the foundation of what comes next. Both are true at once.

The prototype is valuable because it is the best specification you will ever write. Every screen you accepted, every flow you sent back three times until it was right, every table that appeared because you kept asking about a field — those are decisions made with real information, which no document written before the prototype could have contained. We treat it that way: the prototype is the brief.

The code is a different matter, and not because generated code is bad. It was generated by a process that gave you what you asked for. You asked for screens, so you got screens. You did not ask who can see which record, so there is usually one kind of user and it can see everything. You did not ask what happens when a second company signs up, so the data model has no notion of a tenant, and the first customer’s staff are one bad query away from the second customer’s invoices. You did not ask for tests, so there are none, and nobody can change it with confidence. None of that is a flaw in the tool. It is what “prototype” means. Retrofitting permissions, tenancy and tests touches every line written without them, which is why rebuilding from the brief is usually faster than repairing the code.

The honest exception: sometimes the code is fine. If the application is an internal tool for your own team, if there is only ever one tenant, if nobody pays through it and nobody outside the company logs in, then a synced repository and someone who keeps an eye on it may be all you need for a long time. The checklist above still applies, but the rebuild does not. Be clear about which case you are in, because the two diverge the day a second company signs up.

The security checklist a buyer will run

The first business customer sends a spreadsheet, and the order of its rows is roughly the order in which a security team decides whether to keep reading. Here are the ten questions, with what a good answer contains. Our own answers are on the security and compliance pages, including what is not done yet.

1. Is data encrypted in transit and at rest? TLS on every connection, and encryption at rest for the database, file storage and — the clause people miss — the backups.
2. How are backups taken, and how long are they kept? A schedule, a retention period, storage separate from the running system, and the date of the last tested restore.
3. Who can access our data? Access scoped to named people for a reason, and logged. “Our engineers have access to production” ends conversations.
4. Do you support single sign-on? Their staff signing in through their own identity provider, so access ends centrally the day someone leaves — for the application’s users, not only your own dashboard.
5. Is there an audit log? Who signed in, who changed a permission, who exported what, and when.
6. Who are your sub-processors? The third parties involved in running the application — hosting, email delivery, error tracking — by name and purpose.
7. How and when will you notify us of an incident? A defined process with a defined window. Under Quebec’s Law 25 and the GDPR the clock is short, and the obligation is yours whoever built the software.
8. Where is the data stored? Country and region, and whether it can be changed.
9. Has it been penetration tested? By a third party, with a report the customer can read. For Idea to Production this is on the roadmap, not done, and we say so before anyone asks.
10. Are you SOC 2 certified? Idea to Production is not. SOC 2 Type II is in progress, not certified, and the compliance page says so plainly. What exists today is the practice underneath — encryption, access control, audit logging, an incident process — and a written security overview that covers the other questions.

A prototype answers almost none of these, and it is not supposed to. What matters is that the answers exist before the spreadsheet arrives. The questionnaire itself is written up in What a security team actually asks.

If you built it on…

Whichever builder you used, the prototype is the brief and the learning is yours. Here is what each one lets you carry forward in addition, from its own documentation.

Lovable. The code syncs two ways with GitHub on every plan, with GitLab and Bitbucket also supported, as a standard Vite and React project. The built-in backend runs on Supabase, can move to a managed or self-hosted Supabase project, and keeps about fourteen days of daily database backups. Take the repository and a fresh backup. Lovable compared.

Bolt.new. StackBlitz states the code you create is yours for any legal purpose. GitHub sync commits every change, Export downloads the project as a zip, and the built-in database can be claimed into your own Supabase account. Version history restores project files, not the database, so claim the database first. Bolt.new compared.

Replit Agent. A GitHub connection with two-way sync, and a Download as zip option for the whole project. The production database has point-in-time restore — seven days on Core, up to 28 on Pro and Enterprise — and the uptime monitor on paid plans emails you when the app is down. The restore window has a clock on it, so take your own export as well. Replit Agent compared.

v0. A standard Next.js project with two-way GitHub sync, branches and pull requests, and a Download ZIP option; Vercel states it does not own the code generated from your prompts. The database is a Vercel Marketplace resource, Neon by default, in your own Vercel team, so it is already under your account. v0 compared.

Base44. On the Builder plan or higher, the React and Vite front end exports as a ZIP or syncs two ways with GitHub. The database, sign-in, file storage and functions run on Base44’s backend, and running that backend yourself is not documented. You carry forward the front end and, as a specification, the records, roles and permission rules you set up. How the data leaves the backend is the first thing to check. Base44 compared.

Emergent. Emergent states you own everything it generates and may download, modify or host it anywhere; push and pull to GitHub is on Standard and above. The MongoDB database is yours to export with MongoDB’s own tools, and an automatic backup is not documented, so take that export now. Emergent compared.

Rocket.new. Full source download as a ZIP on any paid plan, two-way GitHub sync for Next.js TypeScript projects and one-way push for Flutter. The database, sign-in and file storage are already in a Supabase project you own, so the data never has to move. If the prototype came from a Figma file, you have the design as well. Rocket.new compared.

Databutton. Databutton is now Riff, aimed at procurement and operations teams in manufacturing. The full React and FastAPI source is visible and editable in the code editor; a ZIP export appears only in the archived Databutton-era docs, and a GitHub sync is not documented. The database is a PostgreSQL instance Riff hosts and moving the data out is not a documented path, so ask Riff for an export first. Databutton compared.

What it costs to cross

There are four ways from a prototype that scores two on the checklist to an application that scores nine, and each has a price that is only honest when written out.

Hire. One engineer can build the production version. Keeping it alive — the on-call rota, the holidays, the day that engineer resigns — needs two, for as long as the application earns money. Two salaries, sustained, plus the attention of someone who can evaluate work they cannot inspect. Right for a company that will need an engineering team anyway; wrong for a company that needs a single application to work.

Agency. A quoted scope, a delivery date, six figures. The build is usually fine. The problem is the day after delivery: the agency leaves, and the checklist has nine lines with no name against them. If you go this way, put the nine jobs in the contract, because they will not be in the quote.

Keep doing it yourself. This is the honest default and it is not wrong. Sync the repository, turn on whatever backup and uptime check your builder provides, read the security scan, and keep going. It works until the night it does not — the 2 a.m. page that goes to nobody, the restore that was never tested, the spreadsheet with a deadline. Decide now where you will stop, because that point will not announce itself.

A licence plus usage. This is what Idea to Production sells, so read this paragraph as the vendor talking. You hand over the prototype as the brief. A team rebuilds it with accounts, roles and a data model designed for the second customer, on a backed-up database, on your own domain, and then holds the nine jobs: watching, patching, tested restores, staging and rollback, a name on the incident. You pay a licence for the platform plus the resources the application actually uses — no salary, no equity — and the source is yours. Not included yet: deployment into your own cloud, and the SOC 2 certificate, both on the roadmap. The figures are on the pricing page.

For the after-the-build questions side by side, sourced from the vendors’ own documentation, see the comparison pages. If you would rather describe where you are, contact us with the prototype’s URL. It is the best brief you could send.