Your App Was Vibe Coded. Now What?

Vibe coding is real, and so are its gaps

Owners and staff are building real tools by describing what they want to an AI app builder. That is a good thing. A working prototype in a weekend used to cost thousands.

The catch is that these tools optimize for something that works on screen today. They do not always set up the parts you cannot see: who is allowed to read which records, where passwords and API keys are stored, what happens when two people edit at once, and how you get your data back after a bad day.

Automated scanners now exist for builders who want to check their own code, and they are worth running. This guide is for the owner who needs to know, in plain terms, whether the thing the business now depends on is safe.

Check one: who can see the data

The most common serious problem is data that is visible to anyone who knows where to look. An app can hide a page from the menu while the data behind it is still open. If your app uses a hosted database, check that rules restrict each user to their own records.

• Can a customer see another customer's records by changing a number in the address bar?
• Is there a sign in for every page that shows business data?
• Do former staff still have access?

Check two: where the secrets live

API keys for payment, email, and AI services should live on the server, never in the code that runs in a browser. If a key is exposed, someone else can run up your bill or read your data. If you are not sure, assume it is exposed and rotate it.

Check three: backups you have actually restored

A backup you have never restored is a hope, not a backup. Find out where the data lives, how often it is copied, and how long a restore takes. Then do one restore into a test copy. If no one can, that is the first fix.

Check four: you own the accounts and the code

Apps built on a platform often live under one person's personal login. If that person leaves, so does your access. Move the hosting, database, domain, and code repository to company accounts with at least two admins. Export the code so it is not locked inside one builder.

Check five: can it change without breaking

The second month is where AI built apps usually struggle. Each new request is generated on top of the last, and small changes start breaking things that used to work. Signs you have hit this point:

• Fixing one bug creates another somewhere else.
• Nobody can explain how a key part works.
• There are no automated tests, so every change is checked by hand, or not at all.
• The same logic is copied in several places with small differences.

Questions to ask whoever built it

If a staff member or contractor built the app, these questions tell you a lot in ten minutes.

• Where is the data stored, and who has admin access to it?
• Which API keys does the app use, and where are they kept?
• When was the last backup, and has anyone restored one?
• If you were out for a month, could someone else make a change safely?

What to fix first

Work in order of risk, not order of annoyance. Lock down access and secrets. Set up backups and prove a restore. Move accounts to the company. Then add tests around the parts that touch money and customer data, so future changes are safe. Only after that is it worth cleaning up the code itself.

Most apps do not need a rewrite. They need a careful engineer to harden what is there and set it up so it can grow. A rewrite makes sense only when the core data model is wrong or the platform cannot do what you need.

Questions owners ask