Vibe coding means describing what you want in plain English and letting an AI tool write the code. It genuinely works for getting to a demo, and what it produces is usually a real, running app. What it almost never produces is the part nobody demos: the login that cannot be bypassed, the rule that stops one customer reading another's data, the backup you have actually restored from, and the payment path that does not charge twice.
That gap is not a flaw in the tools. It is a difference in what was asked for. You asked for a thing that works. Production asks for a thing that keeps working when people who do not wish you well are also using it.
The demo and the live system are different products
A demo has one user, who is you, and that user is cooperative. They click the buttons in the order you expect, enter sensible data, and do not try to read anybody else's records. Every AI builder optimises for this user, because this user is the one giving feedback in the first hour.
A live system has users who are tired, in a hurry, on a bad connection, using a browser from 2019, entering an address with an apostrophe in it, uploading a 40MB photo, double-clicking the pay button, and occasionally actively looking for a way in. The code that handles the first user and the code that handles the second are not the same amount of work, and the second is where the months go.
What is usually missing
The same handful of gaps come up, in roughly this order of how much they cost to leave alone.
The login is a suggestion. The app checks whether you are an admin in the browser. That check is a line of JavaScript running on the visitor's own computer, which means the visitor can change it: open the browser's developer tools, set the value, and the admin screen loads. Anything that decides who may do what has to be decided on the server, where the user cannot reach it.
Every customer can read every other customer. Modern app platforms give each table row-level rules about who may read it, and those rules are off by default. If they were never written, then any logged-in user who changes a number in the address bar sees somebody else's invoice. Of everything on this list it has the widest blast radius, and under the Privacy Act 2020 it is the one you least want to discover after launch rather than before.
The keys are in the page. API keys for the payment provider, the email service or the AI model shipped to the browser inside the app bundle. Anyone can read them and spend your money. Rotating them is quick; finding every place they were pasted is not.
There is no way to change the database safely. The schema was built by clicking around in a dashboard, so there is no record of how it got to its current shape and no way to apply the same change to a copy. That makes a test environment impossible, which makes every future change a change made live, on your real customers' data.
Nobody has restored a backup. Backups that have never been restored are not backups. They are a feeling.
Money is not idempotent. The payment webhook arrives twice, because webhooks do, and the app bills twice because nothing told it that this event had already been handled.
It is silent when it breaks. No error logging, so the first report of a problem is a customer email, and there is nothing to read to find out what happened.
None of these are exotic. They are the standard list, and a senior engineer finds most of them in a day.
What is worth keeping, and it is more than people expect
The useful surprise is that the work the AI did well is usually the expensive part to redo, and the work it did badly is usually the quick part to fix.
Keep the interface and the flows. Screens, layout, the order of steps, the wording, the shape of the forms: that is weeks of design thinking you now have for nothing, and it has already been through the only review that matters, which is you using it and changing your mind. Keep the data model if it is sensible, meaning things are in their own tables with proper relationships. Keep the copy.
Replace the foundation. Authentication and permissions, data access rules, hosting and environments, anything touching money, backups, logging. That is a known, boundable piece of work on a system whose behaviour is already decided, which is why it can be quoted as a fixed scope.
There are cases where a rebuild is honestly the cheaper answer, and they are recognisable. If the whole application is one enormous file nobody can read, if there is no version history at all, if the database stores every record as a single blob of JSON, or if the thing it has to do turns out to be quite different from the thing that was built, then you are paying to keep a prototype that is actively in the way. We say so when we see it, and we say so before anybody signs anything.
Four things to do before you call anyone
These are free, they take an afternoon, and they are worth doing whoever you end up working with.
- Get the code out of the platform and into your own repository. Most builders can push to GitHub. Do it today, because this is the step people assume will be easy and occasionally is not.
- Rotate every key the app has ever used, and move them out of the front end.
- Turn on backups and restore one into a scratch copy, to prove the backup is real.
- Write down what the app has to do, in a page of plain English, including the parts that are not built yet. This is the document that turns an open-ended rescue into a fixed price, and nobody can write it except you.
What it costs to find out
If you are not sure whether what you have is worth finishing, start with the expert code review and remedy report, a fixed NZ$1,499. A senior engineer goes through the application and gives you a written report: what is solid, what will break, and what it would take to make it production-ready. You keep the report whether or not you go any further with us, and if it says rebuild, it says rebuild.
If you already know you want it finished, it is scoped and priced like any other project: a senior engineer writes down what will be built and puts one number on it, from NZ$6,999. Nothing gets added without your say-so. You keep your code, your hosting accounts and your data, in your name, at the end.
Key takeaways
- Vibe coding reliably produces a working demo, and reliably leaves out server-side permissions, data access rules, environments, backups, logging and the safety around payments.
- The gap with the widest consequences is every logged-in customer being able to read every other customer's records, because row-level rules were never written.
- The interface, the flows and the wording are usually worth keeping; the foundation underneath them is usually worth replacing.
- Export the code, rotate the keys, restore a backup and write down what the app must do, before you talk to anyone.
- Applicable reviews an existing app for a fixed NZ$1,499 and finishes AI-built apps from NZ$6,999, with the scope and the price written down first.
Faq
Can an app built with Lovable, Bolt or Replit go live for real customers?
Yes, once the parts a demo never needed are added: permissions checked on the server, row-level rules so customers cannot read each other's data, secrets out of the browser, a real environment to test in, backups that have been restored, and error logging. The interface the tool built is usually kept as it is.
Is AI-generated code any good?
It is usually readable, conventional code, which is why it can be picked up and finished. The problem is rarely the quality of a given function and almost always what was never asked for: authorisation, data isolation, error handling and the operational side. A review tells you which of the two you have.
Can Applicable take over an app someone else's AI wrote?
Yes. Applicable keeps what works, fixes the foundation, which means logins, data, security and hosting, and gets it live as a custom web app. It is quoted on a fixed scope from NZ$6,999, and you keep your code.
How do I know if my AI-built app should be rebuilt instead of finished?
The signs are structural: no version history, the whole app in one unreadable file, every record stored as a single blob of JSON, or a requirement that turns out to be materially different from what was built. The expert code review and remedy report, a fixed NZ$1,499, exists to answer exactly this, and it will say rebuild when rebuild is the right answer.
What is the most common security problem in a vibe-coded app?
Missing row-level access rules, so any logged-in user who changes an identifier in the address bar can read another customer's records. Second is authorisation decided in the browser, where the user can change it, and third is API keys shipped inside the front end.
Do I own the code if Applicable finishes my AI-built app?
Yes. The repository, the hosting accounts and the data are in your name, and there are no licence fees. That is how every Applicable project ends, not a special arrangement for rescued apps.
