From Lovable and Cursor Prototype to Production: The Migration Checklist

An AI IDE like Lovable, Cursor, Claude Code, Bolt, v0, or Replit gets you to a clickable product in days. That is real progress, and it is also the easy part. The distance between "the demo works" and "real users can rely on this" is a separate project with its own scope, and pretending otherwise is how launches go wrong. This is the checklist we run when a prototype needs to become production-grade.

None of this is a knock on the tools. They are how we start too. It is a map of the work that does not happen on its own, so you can plan for it instead of discovering it during an incident.

What "production" actually means

A demo proves the idea. Production carries the weight. The difference is not polish, it is a set of guarantees that nobody sees until they are missing.

• Auth that holds. Real accounts, real sessions, and a hard rule that one user cannot reach another user's data.
• Data integrity. Writes that either complete or roll back cleanly, and a store you trust to still be correct next month.
• Uptime. A deploy that survives a restart, a traffic spike, and a bad release without a manual rescue.
• Security. No keys in the browser, no open endpoints, no dependency you have not looked at.
• Observability. When something breaks at 2am, you find out from a tool, not from a customer.
• Support. A way to answer "what happened to my order" without guessing.

A prototype can skip every one of these and still demo perfectly. That is exactly why the demo is not the finish line.

Step 1: Lock down auth and data access

This is the first thing we check and the most common thing that is wrong. AI IDEs are very good at building a login screen and very bad at enforcing what happens after login. The frontend hides the button, but the API still answers anyone who asks.

Every access check has to live on the server. Move authorization out of the client entirely and enforce it where the data is read and written. If your product is multi-tenant, isolate by tenant or by row so one account physically cannot query another's records, ideally at the database layer rather than in app logic you have to remember to add on every endpoint. A frontend check is a UX nicety. It is not security, and it never was.

Step 2: Own your data layer

Many prototype tools hand you a convenient shared or throwaway data store to get you moving. That is great for a demo and wrong for production. You do not control its backups, its limits, or its lifetime, and "the data got reset" is not a sentence you want to say to a paying user.

Move to a real managed database you own, Postgres in most cases. Put your schema under version-controlled migrations so changes are repeatable and reviewable instead of clicked into a dashboard. Turn on automated backups and actually test a restore once, because a backup you have never restored is a hope, not a backup. This is usually the least glamorous step and the one that saves you the worst day.

Step 3: Secrets and environments

Prototypes leak keys. The tool inlines an API key so the example runs, and it ends up in the client bundle or the repo history where anyone can read it. The first job here is to get every secret off the client and onto the server, behind your own backend.

Then separate your environments. Dev, staging, and production should have their own keys and their own data, so a test never touches a real customer and a mistake in staging cannot bill anyone. And rotate anything that was ever exposed. A key that sat in client-side code or a public commit is compromised whether or not you have proof it was used. Rotating it costs an hour. Assuming it is fine can cost a lot more.

Step 4: Hosting, CI/CD, rollbacks, observability

The prototype host that came bundled with your AI IDE is built for showing, not for running. Move to a real deployment setup before you depend on it. That means a pipeline that builds and ships on a push, a way to roll back to the last good version in seconds, and a staging step so changes are seen before users see them.

Then add eyes. Error tracking that tells you when something throws, basic uptime monitoring, and enough logging to answer "what happened" after the fact. The goal is simple: you should learn about a problem from your tooling, not from an angry message. Without this layer you are flying blind, and the first sign of trouble is a user who already churned.

Step 5: The keep-vs-rebuild decision

Not all generated code needs to be thrown away, and not all of it is worth keeping. The honest answer is that it depends on where the problems live. Surface-level gaps are cheap to close on top of what you have. Foundational ones are not.

Keep the foundation when the data model is sound, the structure is readable, and the gaps are the predictable ones above: auth, validation, error handling, secrets. Those are additive fixes on a decent base. Rebuild the core when the data model is wrong in a way that everything else depends on, or when the same broken pattern is copied across the whole codebase so every fix has to be made a hundred times. Patching a foundation that needs to be poured again is the most expensive way to save money, and we will say so on the first call rather than bill you for the long way around.

"The prototype was never the project. Getting to a demo is one job and getting to production is another, and the second one does not get cheaper because the first one was fast."

How long and how much

From experience, a focused hardening pass on a typical AI-built prototype runs one to three weeks. That is a range, not a quote, and it moves for two reasons: how much real money or sensitive data the product touches, and how far the tool ran without anyone steering it. A read-only internal tool sits at the short end. A product that takes payments and stores personal data sits at the long end and may need more.

What we will not do is hand you a precise number before we have looked. Anyone who quotes a fixed figure for a codebase they have not seen is guessing, and the guess is always optimistic. We scope it after a first look, and if the honest answer is "rebuild the core," you hear that first, not on week three. The detailed version of this work is our software QA service, and the failure modes behind it are covered in QA for AI-generated code.