The demo went well. You described the app to Lovable or Replit Agent, or you spent a few weekends in Cursor or Windsurf, and now there is a working product with a login screen, a dashboard and a handful of people who want to use it. Then someone asks whether it is safe to put real customer data in it, and nobody on the team can say yes with a straight face.
That is the point where most vibe-coded projects stall. The app works. What is missing is the layer nobody sees in a demo: who is allowed to read which rows, where the API keys live, what happens when a payment webhook arrives twice. This post is the checklist we use when a founder or product lead sends us an AI-built prototype and asks what it will take to launch it.
Why AI-built prototypes stall before launch
AI coding tools are very good at the first version. They build the screens you asked for, wire up a database and make the happy path work. They are much less reliable at the things you did not ask for, because you did not know to ask.
A prompt like “add a page where users can see their invoices” will usually produce a page that shows invoices. Whether it only shows that user’s invoices depends on details the model may or may not have handled. On demo data with one test account, you cannot tell the difference. With 200 real customers, you can.
There is a second problem that builds up more slowly. When code is generated faster than anyone reads it, the team ends up with an app that works but that nobody fully understands. We call that comprehension debt. It does not hurt on day one. It hurts the first time something breaks at 2 a.m. and nobody knows which of 40 generated files to open.
The production gap, piece by piece
These are the areas we check first on every rescue, roughly in this order.
Sign-in and permissions
Generated apps often have authentication (you can log in) without real authorisation (the server checks what you are allowed to do). Look for pages and API routes that trust an ID sent from the browser. Try loading another user’s record by changing a number in the URL. If it works, that is the first fix.
The data model
The schema a tool generates is shaped by the order you asked for features, not by how the data really relates. Expect duplicated fields, missing foreign keys and no migrations, just a database that was edited in place. Before launch you want a schema you can change safely and a way to roll it forward and back.
Secrets and keys
Search the repo and the built front-end bundle for API keys. Prototypes regularly ship a payment or AI provider key to the browser because that was the quickest way to make the feature work. Anything with spending power or admin rights belongs on the server, and any key that was ever exposed should be rotated.
What happens when things fail
Call an external API with the network off. Submit a form twice. Send a webhook with a bad signature. Generated code tends to assume every call succeeds, so failures show up as blank screens or, worse, half-written records.
Tests
Most prototypes have none. You do not need full coverage before launch, but you do need tests around the parts where a bug costs money or leaks data: login, permissions, payments and anything that deletes.
Tool-specific things to look for
Each tool leaves its own fingerprints. None of this is a criticism of the tools. They are doing what they were asked.
Lovable apps usually sit on a hosted Postgres backend, and the access rules on each table decide who can read what. Check that those rules exist and match your roles, because placeholder auth and permissive defaults are common in early builds. Payments and webhooks are the other usual gap. Our Lovable experts page covers what we change and what we normally keep.
Replit Agent builds can run on Replit’s own hosting, which is fine for a prototype. The questions are uptime, scale and whether the app needs a backend or integrations the agent did not build well. You do not always have to leave Replit. Sometimes staying is the right call, and sometimes moving is. More on that on our Replit experts page.
Cursor and Windsurf projects are different because a developer was in the loop, so the code is usually more conventional. The risks there are subtler: code that looks right in isolation, APIs the model invented, and drift between parts of the codebase written months apart with different context. Both editors let you set project rules, and teams that skipped that step tend to have several styles fighting in one repo. See our Windsurf experts page for how we audit these builds.
A security review checklist for AI-generated code
If you only have an afternoon, go through this list.
- Every API route checks the logged-in user on the server, not only in the UI.
- No secret keys in the client bundle, the repo history or shared screenshots.
- Database access rules are switched on and tested with two different accounts.
- User input that reaches a query, a shell command or an AI prompt is validated.
- File uploads have type and size limits and are not served from a path users can guess.
- Webhooks verify their signatures and handle the same event arriving twice.
- Dependencies are real packages. Models sometimes suggest package names that do not exist, and someone can register them.
- Errors are logged somewhere you will actually look, without logging passwords or tokens.
An automated review pipeline can catch a lot of this on every pull request once the app is live. We wrote about that on our AI code review page.
Rescue or rebuild?
Most of the time the answer is rescue. A rebuild throws away working screens, real user feedback and the domain knowledge baked into the prototype, and it resets the clock. We keep what is solid and fix or replace the parts that put users or data at risk.
A rebuild starts to make sense in a few cases. The data model is so tangled that every fix breaks something else. The app needs a backend the original tool was never designed to produce. Or the codebase is small enough that rewriting the core is faster than understanding it. Even then, the prototype is still useful as a specification. It shows exactly what the product is supposed to do.
A useful test: ask an engineer to make one small, real change, such as adding a field to a form and saving it. If that takes an hour, rescue. If it takes two days and breaks login, think harder.
How to pick a rescue partner
You are trusting someone with an app that already has users, so ask direct questions before you sign anything.
Ask whether they use AI coding tools themselves. A team that does not will tend to treat your codebase as something to replace. A team that does will know the specific ways these tools go wrong. We use Cursor and the other major AI coding tools in our own delivery, which is how we learned where they cut corners.
Ask what they look at first and what they need from you. You should hear something concrete, like repo access, a list of user roles and the two flows that matter most. Be wary of a vague “full assessment” with no end date.
Ask how AI-written changes get reviewed on your project. The answer you want is that they go through the same review, tests and security checks as hand-written code, and nothing ships on the agent’s say-so alone.
Ask what you will have at the end. You should own the code, and the team should leave it in a state your next engineer can pick up.
What a hardening engagement usually covers
We do not publish fixed prices for rescues, because the work depends on the app. The things that drive scope are fairly predictable: how many user roles there are, whether money moves through the app, how many outside services it talks to, how much real data already exists and has to be migrated, and whether you want to stay on the original platform.
A typical engagement starts with a review of the repo and a written list of what to fix, in priority order. Then comes the work itself, usually auth and data first, then integrations, failure handling and tests. It ends with handover notes and, if you want them, project rules for your AI tools so the next round of generated code follows the same conventions. Once we agree to go ahead, the first result usually lands 7 to 10 days later. For a rescue, that first result is usually the review and the most urgent security fixes.
Our team is in Ahmedabad, India, and the company also has a US entity in Newark, Delaware. We work in your repository and your channels, and we agree the overlap in hours when we scope the work. Our vibe coding services page has the wider picture, including governance for companies where many teams are generating code.
Send us your repo
If you have a Lovable, Replit, Windsurf or Cursor build that works in a demo but you are not sure it is ready for real users, book a 15-minute call. Tell us what the app does and who uses it. We will tell you honestly what it needs before launch, and whether that is a rescue or something bigger.
