From AI Prototype to Production: A Checklist for Vibe-Coded Apps

An AI prototype proves an idea. A production app keeps working when real people use it, every day, with real data and real money. Getting from one to the other is mostly about the work nobody sees in a demo.

This checklist is the one our engineers use when a founder hands us an app built with Lovable, Bolt, Replit, Cursor or a similar tool and asks, “what does it take to launch this?” Work through it in order: each group depends on the one before it.

Before you start: decide what you are keeping

Not every prototype should go to production as it is. Spend an hour answering three questions first:

1. Which flows must work on day one? Usually sign-up, the one core action and payment. Everything else can wait.
2. Which parts of the code are sound? Screens and simple flows often are. A data model the AI invented one prompt at a time often is not.
3. Keep, fix or rebuild? Mark each part of the app. Most prototypes are a mix, and rebuilding everything is rarely the cheapest answer.

1. Sign-in and access

• Sign-up, sign-in, password reset and sign-out all work, including on mobile.
• Every page and API call checks who is signed in, on the server.
• Each role (user, admin, team member) can see and change only what it should.
• Signed in as one user, you cannot read another user’s data through the API.
• Sessions expire, and signing out really ends the session.

2. Data

• The data model has been reviewed: tables, relationships and required fields make sense for the product, not just the demo.
• Every table has access rules (for example row level security), and they have been tested.
• Empty, duplicate, wrong and oversized input is rejected with a clear message.
• Changes to the database run as migrations, not as manual edits.
• Backups run automatically, and one has been restored as a test.

3. Security

• No API key, password or token is in the browser or in the code repository; exposed keys have been rotated.
• Paid and private APIs are called only from the server.
• Dependencies are current, and a dependency audit shows no critical issues.
• The app has been checked against the common web risks in the OWASP Top 10, such as injection and cross-site scripting.
• Rate limits protect sign-in, forms and any endpoint that costs money to call.

If you only do one group properly, make it this one. Our article on whether vibe coding is safe for production explains each risk in more detail.

4. Tests

• The flows from “Before you start” have automated tests.
• Tests run on every change, before it is merged.
• A bug fixed once gets a test, so it cannot quietly come back.

AI tools make changes fast, which is exactly why tests matter: without them, every new prompt can break something that used to work.

5. Performance

• The main pages load quickly on a phone with an average connection.
• Slow database queries have been found and fixed (usually with an index or a smaller query).
• Lists and searches are paginated instead of loading everything at once.
• The app has been tried with realistic data volumes, not the ten test records from the demo.

6. Running it

• Errors are logged in one place, with enough detail to fix them.
• Someone gets an alert when errors spike or the app goes down.
• Deployment is repeatable: one command or one pipeline, not a sequence someone remembers.
• There is a separate test environment, so changes are tried before users see them.
• Costs for hosting and AI APIs are monitored, with a limit set.

7. Ownership and handover

• You own the code repository, the hosting account, the domain and every third-party account.
• The code is documented well enough that a new engineer can run it in a day.
• Privacy basics are in place: a privacy policy, cookie consent where needed, and a way to delete a user’s data.

How long does this take?

It depends on how much of the prototype is sound, which is why the checklist starts with keep, fix or rebuild. A small app with a clean structure may need a few targeted fixes. An app whose data model was invented prompt by prompt may need that part rebuilt before anything else is safe. An audit tells you which case you are in before you commit to a budget.

Get it done with engineers who have shipped this before

If you want the checklist worked through for you, our vibe code audit and cleanup starts with a written audit of your app, ranked by risk, then fixes it in that order. If you are still at the idea stage, our vibe coding services build the prototype with these checks in place from the start, so there is less to fix later.