Vibe code rescue. Then someone keeps it running.
You described what you wanted, the tool built it, and it works. Now other people use it, and it holds data you would not want to lose. Keeping it that way is a different job from the one that got it built.
An application generated this way can be perfectly reasonable code with nothing around it. The database may accept requests it should refuse. A key that belongs on the server may be sitting in the browser. There may be no backup, or a backup nobody has restored. None of that shows up while you are the only user.
If you searched for a phrase and landed here, the phrase is probably below. If it is not, send it to me anyway.
It starts with an audit, and the audit is the deliverable
Fixed price, agreed before it starts, so the first thing you buy is an answer and not an open-ended engagement. What comes back is a written list of findings, each one in one of two groups:
- Blocks going live. Anything that can lose data, expose it, or let the wrong person through. These get an estimate and a suggested order.
- Untidy but working. Structure, duplication, naming, missing tests. Real, worth knowing about, and not a reason to delay anything.
The list is yours. Take it to your own developer, or hand it straight back to the AI tool that wrote the app. If two findings matter and the rest can wait, the list says that, and you do not need me for the rest.
What usually turns up
Row-level security left off, or written so it passes everything. Hosted database platforms ship with direct access from the browser, which is what makes them fast to build on. The rules deciding who sees which row are a separate step, and an app behaves correctly without them for as long as there is only one user, which during building is you.
What to checkOpen the app signed in as one customer and try to read a second customer’s record by changing the identifier in the request. If it comes back, that is the finding.
A key that was meant for server-side use, shipped inside the JavaScript the browser downloads, or committed early and still in the repository history after being deleted from the current files. Anyone can read the first. Anyone with access to the repository can recover the second.
What it costsWith a model provider key it is your bill. With a database or payment key it is more than that.
The button is hidden from users who should not press it, and the request behind the button is not checked on the server. Hiding a control is a courtesy to the user, not a permission check.
What to checkWhether every endpoint that changes or returns something decides for itself who is calling, without trusting what the interface sent.
Usually one of two things. Either the same logic exists in several places and only some copies got updated, or there are no tests, so nothing tells you which change caused which break until a user does. Both get worse the longer the app stays useful.
What helps firstTests on the few paths that carry money or data. Enough to tell you when you broke the important part, which is a smaller job than covering everything.
Configuration that exists on your machine and not on the server, or a preview environment that talks to the same database as production. The second one is the expensive version, because your test data and your real data are the same rows.
On the builder platforms one balance usually pays for two different things. Lovable’s own documentation puts it plainly: one credit balance covers building your app, hosting it and running its built-in backend, and the AI features your deployed app uses. Cloud usage is driven by database instance size and uptime, stored data, network traffic, file storage and compute.
Why it feels wrongThe cost stops tracking your work and starts tracking your users. Nothing has gone wrong, and nobody is overcharging you. It is simply that a platform priced for building is now mostly hosting, and hosting is the cheaper half of the market to buy elsewhere.
What to checkStop editing for a week and watch the balance. If it still falls, you are paying to run rather than to build, and that number is the one to compare against ordinary hosting.
The failures that are not in the code
These arrive later, and they are the reason an app that has been fine for six months stops on a Tuesday. A certificate that renewed silently for a year and then did not. Logs growing until the disk fills, at which point nothing can even write the error. A scheduled job that finishes green every night and writes no rows, because a field upstream got renamed.
No AI tool prompts you to set any of this up, because none of it is part of building the thing. I wrote up the symptoms and what each one means in two ways a self-built app fails.
When it stops being finishable
A different situation, and the one people describe most often as being stuck. The app is nearly there. Then every new feature breaks something that already worked, the fix breaks a third thing, and a week goes by with the same number of working features you started with.
Usually not because the app is badly written. Three things arrive together as it grows. The same rule ends up written in several places, so a change updates some copies and not others. There are no tests, so nothing tells you what broke except a user. And the app gets bigger than what the assistant can hold at once, so it starts re-deriving decisions it made earlier and contradicting them.
Why more prompting does not clear itEach fix is reasonable on its own and is made without sight of the whole. That is the same condition that produced the problem, so repeating it tends to add another copy of the rule rather than remove one.
What actually helpsSomebody reads the whole thing once, end to end. Then the duplicated rules get collapsed into one place and the few paths that carry money or data get tests. After that the assistant works well again, because the ground under it stopped moving.
Worth saying plainly: you are often closer than it feels, and this is usually a smaller job than a rebuild. The audit answers which, and it answers before you commit to either.
Moving it off the platform
This comes up more than anything else wherever these apps get discussed, and it is a normal stage rather than a failure. A builder platform is priced for building. Once an app is mostly running, you are buying hosting at build prices, and hosting is cheap to buy on its own.
You own what you would be moving. Lovable’s FAQ says so directly: you own your apps, the customer data stored in them, and the AI output. Nothing here has to be negotiated with anyone.
Three things have to come with you
- The database and its rows. The schema and the live data, including the users. This is the part people worry about most and usually the most straightforward.
- Configuration and secrets. Environment variables, API keys, webhook URLs, anything the app reads at startup. Scattered by nature, so it usually gets found when something breaks.
- The parts the platform was doing invisibly. Authentication, file storage, scheduled jobs, email sending. This is what breaks migrations, because nothing lists it anywhere. It was never a file you wrote.
A first test that costs nothing: export the database, and try running the app somewhere else pointed at that copy. Whatever fails is your real scope, and the list is normally shorter than it looks from the outside.
Compare one number against one number. What the platform costs you per month now, against ordinary hosting plus the one-time move. If the app is small or still changing shape every week, stay where you are, because the platform is genuinely faster for that. The move pays when the app has stopped changing much and started being used a lot.
How the work moves
Audit
I read the code and the deployment. You get the written list, grouped into what blocks going live and what does not, with an estimate against each item. Fixed price, quoted first.
Fix what you decide to fix
You choose from the list. Priced per item from the audit, so nothing is a surprise, and you can stop after the blocking findings if that is all you want. Moving the app onto your own hosting is one of the items, quoted the same way.
Keep it running
Backups that have been restored once, alerts that fire before the disk is full, certificates watched, dependencies updated, and someone who answers when it stops. Monthly, and you can end it whenever the app stops mattering.
Every competing offer I have read stops at stage two and hands the app back. That works when you have a team to hand it to. If the app was built without one, the same gap that produced the findings is still there the week after they are fixed.
Who this suits
- The app already does real work. Customers, orders, records, money. Not a prototype you are still deciding about.
- There is no in-house developer. If you have engineers, they can do most of this and will do it cheaper.
- You want to keep the app. If it needs replacing, an audit that says so is the cheapest way to find out, but that is a different project.
Honest scope: none of this is secret knowledge. Everything on this page can be learned and done by the person who built the app, and the audit list is written so you can act on it without me. What it is not is a one-time job, and that is the part that decides whether it actually gets done. Also worth saying plainly: I have got some of this wrong first, on my own systems, which is where most of the list comes from.
Decide whether your app needs a separate audit
The paid decision session is an external assessment of the next step. It can help decide whether a separate technical audit is warranted, but it does not include code review, security testing, or remediation.
View the decision session →