When to stop vibe coding and bring in a developer

Say you run a six-van electrical contractor in Phoenix. Your office manager got tired of the job spreadsheet, so in the spring she described what she wanted to Lovable until a working app came out the other end. Logins, a schedule view, photo uploads. Four people use it every day, and nobody has opened the spreadsheet since.

Then a customer asks where their address and card details are kept. Nobody in the building can answer.

Knowing when to stop vibe coding comes down to one line: the app now holds data that belongs to someone other than you. Before that line, the only thing at risk is your own time. After it, you're keeping a stranger's personal details in software nobody has read, and the repair costs more than the build did.

Vibe coding, if you haven't heard it called that, means building software by describing it to an AI tool and shipping what comes back without reading much of the code. It works, which is the part most security write-ups skip. She shipped in a weekend what an agency would have quoted six weeks for.

When should you stop vibe coding and hire a developer?

Stop when the app crosses one of four lines, not when the code starts to look untidy.

• It holds personal data about people who are not on your payroll: customers, patients, tenants, job applicants.
• Money moves through it, or it tells somebody else what to invoice.
• It is the only place a process lives, with no spreadsheet or paper trail left to fall back on.
• Someone outside your team logs in, whether that is a client, a subcontractor or an auditor.

None of those lines is about quality. Code an AI wrote can be tidier than code a tired human wrote at 11pm, and the app can still be a liability, because the failure is rarely in the code that got written. It is in the part nobody thought to ask for. If three people track van stock in an app that holds no customer names, carry on. Add a feature on Friday.

What breaks first in a vibe coded app?

Access control, nearly every time. The app checks that you are logged in, then hands over whatever you ask it for.

OWASP, the Open Worldwide Application Security Project, puts broken access control at number one in its Top 10 for 2025, and reports that every application in its test data showed some form of it. That covers web apps in general. AI-built ones start from a worse position, for a dull reason.

Most of these apps talk to a Postgres database straight from the browser using a public key. Supabase's own documentation is blunt about what follows. A table in an exposed schema without row level security (RLS, the Postgres feature that decides which rows a given user may see) is readable and writable by any role with a grant on it. The key sitting in the browser isn't a secret and was never meant to be one. RLS stands between your customer list and the open internet, and it does nothing until somebody turns it on.

Plenty of people shipped without turning it on. The National Vulnerability Database record for CVE-2025-48757, the US government's catalogue of reported software flaws, describes insufficient RLS in Lovable apps through April 2025, which let unauthenticated attackers read or write arbitrary tables of the generated sites. Lovable disputes the record, and its position is that each customer of the platform is responsible for protecting its own application data. Read that part twice if you built something there.

Platforms slip as well. In July 2025, Wiz Research disclosed an authentication bypass in Base44: with nothing but an app ID copied out of a public URL, anyone could register a verified account on a private app and walk past its single sign-on. Wix patched it inside 24 hours. The apps at risk were internal ones, HR tools and knowledge bases.

The four checks we run before touching the code

When a business hands us an app like this, we don't start by reading the code. We start here, and the first two items are not programming at all.

1. Who owns the accounts. The platform login, the code repository, the domain, the database, the service that sends your email. If any of it lives in a personal Gmail or a freelancer's account, that is the most urgent line on this list, and it takes an afternoon to put right.
2. Whether the data will come out. Not in theory. Run the export, open the file, count the rows against what the app shows. A business holding a clean copy of its own records has choices. One that can't get a copy is negotiating from a weak position, which is the practical half of the code ownership question.
3. Who can read what. Make a second account, log in as both, then change the record ID in the address bar. If account A can see account B's job, the number one risk on the OWASP list is sitting in your own app, confirmed in ninety seconds.
4. What happens when it breaks at 2am. Most of these apps log nothing and alert nobody, so the first report of a broken booking form arrives from the customer who couldn't use it. Silence looks exactly like success, which is the trap we described in automations that stop quietly.

We have turned down code audits because check one came back wrong. A company that doesn't own its own domain has a bigger problem than a missing RLS policy.

Should you rebuild a vibe coded app from scratch?

Usually not, and that answer costs us billable work. There are three outcomes, in roughly the order we land on them.

Leave it alone. Internal users, no outside data, a fallback that still exists. Nothing we would charge for beats carrying on as you are.

Harden it. The code stays. We turn RLS on table by table and move the keys that bypass it onto a server where the browser can't reach them. Every secret that ever sat in the commit history gets rotated, not just the ones in the current files. Backups go on a schedule, and we restore one to prove it works. Then errors get wired to somewhere a human actually looks. Two or three weeks, usually.

Replace it. The right call when the data model is wrong in a way that touches every screen, or when the thing should never have been an app. Say you run an interior fit-out firm in Dubai Marina, and the client portal your team built is really a status field and three emails. That wants an automation and a shared view, not a web app with its own login and password reset to get wrong.

Where paying anyone for this is a waste

If your tool has four internal users, holds nobody's personal data, and sits beside a spreadsheet you could go back to tomorrow, then paying us to harden it is money badly spent. Keep building it yourself.

Here is the part that costs us more to admit. Taking over an app a model wrote is slower per hour than starting clean. We read to find out what it does, then test to find out what it does when the input is wrong, and neither shows up on a screen you can look at. You pay for three weeks in which your app appears identical. Now and then we read the code and quote a replacement, because honest reading costs more than honest rebuilding, and that is an uncomfortable estimate to send someone who is proud of what they made in a weekend.

What changes for vibe coded apps in 2027?

The quiet deadline is the database underneath. The PostgreSQL project supports each major version for five years, then ships one final minor release and stops, which its versioning policy sets out plainly. Version 14's last scheduled release lands on 12 November 2026. An app spun up in 2024 on a managed Postgres 14 instance will keep running perfectly well after that date, and will keep receiving security fixes from nobody.

Platform defaults are moving in the same direction as the risk. Supabase now documents the anon key as the legacy form of its publishable keys, and treats least privilege grants plus RLS as the baseline rather than the upgrade.

None of that is a forecast. Those are published dates and a published policy. Nobody who typed an app into existence last year has a database upgrade in the calendar, and that bill arrives as either an outage or a breach notice.

So start with the ninety second test. Second account, both logged in, change the record ID in the URL. If account A can see account B's data, stop adding features today and fix that instead.

Then, if you want a second opinion, tell us what you built, what it holds and who logs in, and we will tell you which of the three outcomes applies. Not a quote, just a conversation. What the work looks like after that is on the custom software page.