Rescue for apps built with AI coding tools: from working demo to production

Why AI-built apps fail in production

AI coding tools such as Lovable, Bolt, Replit, v0 and Cursor are good at producing an app that looks and behaves right when one person clicks through it. Production is different: many users at once, some of them hostile, real money, real personal data, and changes made every week.

The faults that appear are rarely in what you can see. The screens usually work. The problems sit underneath, in parts nobody asked the tool about:

• Who can see what. The tool built a login, but the database will hand any row to anyone who asks the right way.
• What happens when something fails. The payment gateway times out, the network drops, the user double-clicks. The demo never did these.
• What changed and how to undo it. Each prompt rewrote several files. There is no record of which change broke checkout.

This is a kind of software rescue, with its own checklist. WavX takes over these apps, reviews them, and repairs or rebuilds the parts that put data and money at risk.

The most common fault: open data

Apps built on Supabase, which Lovable integrates with for its database, authentication and server functions, let the browser talk to the database through a public API. That is a reasonable design when access rules in the database are correct, and a serious exposure when they are missing.

Supabase states it plainly in its documentation: enable Row Level Security on every table in an exposed schema, because a table in an exposed schema without it is readable and writable by any role with a grant on it. The same documentation says a secret key bypasses those rules and must never be used in the browser. Lovable's own documentation says missing RLS policies are the most common way app data gets exposed, and that its tool runs automated checks for RLS coverage.

An automated check is a start. It cannot tell whether a policy that exists is the right policy: whether a customer can only see their own orders, whether a staff member can edit prices, whether a deleted user's data is really gone. That takes a person reading the rules against how the business works.

The review checklist

WavX reviews AI-built code against a fixed list. The security items follow the categories of the OWASP Top 10:2025, which puts broken access control first.

You receive the findings in plain language, each marked urgent, important or cosmetic, with a recommendation.

Repair, harden, or rebuild

The first job in every case is the urgent list: lock down open data, rotate any exposed keys, and take a backup. That comes before any other change is made.

What you need to give us

• The code, exported to a Git repository your company owns. Lovable, for example, documents export and two-way sync with GitHub; for other tools, use their export or download option.
• Admin access to the database and hosting, such as the Supabase project and the hosting account.
• Access to third-party accounts: payment gateway, email, SMS, analytics.
• A list of what the app is supposed to do, and what currently goes wrong. Screenshots and user complaints are useful.

If accounts sit in a personal login of a former developer or co-founder, the steps in what to secure when your developer leaves apply here too.

What it costs

The review is quoted once we have seen the size of the codebase, and repair is quoted after the review. WavX does not publish a figure for rescue work, because it depends on what the review finds.

For comparison, the model behind the software cost estimator puts a rebuild of a small custom web application with roles and payments (base ₹4,50,000 + auth and roles ₹60,000 + payments ₹90,000) at a planning range of ₹5,10,000 to ₹7,50,000. If repair is quoted near that figure, a rebuild deserves serious consideration.

Timeline

1. Access and urgent fixes. Open data closed, keys rotated, backup taken.
2. Review. The checklist above, delivered as a written report.
3. Decision. Harden, repair the core, or rebuild, with a quote.
4. Repair. Urgent items first, then important ones, with tests added around each fix.
5. Ongoing. New features on a codebase that can take them, whether or not you keep using the AI tool.

When you do not need this

• The app is an internal prototype with no real data. Keep iterating with the tool; review before real users arrive.
• It holds no personal or payment data and only a few people use it. Turn on the tool's own security checks and fix what they flag.
• A standard product would do the job. If what you generated is a store, a booking page or a form, a hosted product may be cheaper to run than any custom code. The no-code versus custom guide helps decide.

The website security checklist is a useful self-check before you ask anyone for a review.