Vibe coding: what to check before real people use it

You had the picture in your head for years. The app, or the website that finally looks the way you always wanted it to. For most of that time the gap between the picture and the real thing was a wall called “I can’t code”, and the wall didn’t move. Now it’s gone. You described the thing, the AI built it, and it came out looking brilliant. That “why was this ever hard” feeling is real, and you’ve earned it.

Here’s the one thing worth knowing on the way through. Software has been a profession for fifty years, and it isn’t because the people doing it were guarding the easy bits. It’s that the part you can see, the part that looks finished, was never the hard part. The hard part is the stuff that doesn’t show up on screen. AI is brilliant at the part you can see and quiet about the part you can’t, which is a lovely combination right up until other people start relying on your thing.

So this is the map of the invisible part. Not to scare you off, because you should absolutely keep building, but so you know where the few real traps are and can check for them in about the time it takes to make a coffee. Most of them are a single question to the same tool that built the app.

First, work out which game you’re playing

The most useful question before you touch anything: who is actually going to use this? The answer changes everything, and most of the traps below only switch on when the answer is “people who aren’t me”.

There’s a spectrum, and knowing where you sit on it tells you how much of this guide applies to you.

1 Just you Your machine, your data. Close to risk-free.

2 People you know A few invited users. A bit more care.

3 Real users Strangers' data or money. Run the checks.

Just you, on your own machine. A tool that sits on your computer and does a job for you. This is paradise and it’s close to risk-free. No one else’s data, no one else’s money, nothing hanging off the public internet. If this is where you are, you can skip nearly all of what follows and enjoy it. A huge amount of brilliant building never needs to leave this stage, and that’s not a lesser version of the thing. It’s the whole point for plenty of people.

You, plus a few people who know you. A small step up. A bit more care, not much.

Real users. Strangers. The open internet. This is the line. The moment someone you’ve never met can log in, hand over their email, their photos or their card, the stakes flip. Everything below is about this stage.

The line that matters. It isn’t “is my app big”. It’s “is someone else’s data or money running through it”. A tiny app with ten real users and their personal details carries the same exposure as a giant one. Scale doesn’t protect you. The check does.

Right. If you’ve crossed that line, or you’re about to, here’s the list, in the order the traps actually bite. None of it is hard.

1. Lock the database before anyone logs in

This is the big one, the mistake behind almost every vibe-coded app that has ended up in the news. Your app’s data lives in a database, usually Supabase or Firebase, and by default the front door can be wide open.

Here’s the bit nobody explains. Your app talks to that database using a key that is meant to be public and visible in the app. You can’t hide it, and you’re not supposed to. What keeps your data safe is a set of rules that say who is allowed to read and write what. In Supabase those rules are called Row-Level Security. If they’re switched off, or there are no rules, anyone who opens their browser’s developer tools, copies that public key and types a one-line request can read the lot. Every name, email, address and message.

This is not a maybe. In 2025 a researcher scanned apps built on Lovable and found roughly 170 with their databases readable by anyone, logged as CVE-2025-48757. An AI social app called Moltbook leaked 1.5 million keys the same way, found by the security firm Wiz. The Tea app left a storage bucket open and about 72,000 images, including selfies and ID photos, walked out the door. Same mistake every single time.

The check, word for word, into your tool: “Is Row-Level Security turned on for every table in my database, and does every rule restrict each user to only their own rows? Show me each table’s rule and flag anything an anonymous, logged-out request can read.” Then test it yourself: log out of your own app and try to load the data. If anything comes back, the door is open.

The trap. The tool’s own checker often says “Row-Level Security is on” and stops there. On is not the same as correct. A rule can be switched on and still let everyone read everything. Ask to see the actual rule, not just whether one exists.

2. Get your secret keys out of the browser

Some keys are meant to be public. Plenty are not, and AI has a habit of pasting the private ones straight into the part of the app that anyone can see.

Think of keys to your payment system (Stripe), your AI provider (OpenAI), or the admin-level key to your database as passwords. If they end up in the code that runs in a visitor’s browser, you’ve handed them to every visitor. Bots scan the public internet for exactly this, around the clock.

A developer on Hacker News watched a leaked key rack up $300 of someone else’s usage in two days. The security firm Escape.tech scanned thousands of vibe-coded apps and found hundreds of exposed secrets in their write-up.

The check: “Search my whole project, including the code that runs in the browser, for any secret keys or passwords. Anything starting with sk-, sk_live_ or service_role, or any API key. Move them to the server side and tell me exactly which ones were exposed.” Then change every exposed key in its own dashboard. A key that has been public is burnt, even after you move it. Regenerate it.

3. Make the lock real, not just hidden

Hiding a button is not the same as locking a door. AI loves to tuck the admin panel or the paid feature out of sight in the design, while leaving it wide open underneath.

Access control means the server checks “are you allowed to do this” every single time, not just “should I show this button”. If the only thing stopping a normal user from reaching the admin screen is that the button is hidden, anyone who pokes around in their browser can walk straight in.

One founder built a sales tool with AI and “zero hand-written code”, and launched to a round of applause. Within 72 hours people had got past the paywall by editing a single value in their browser, run his API bills through the roof and filled his database with junk. When he asked the AI to fix it, it broke other things, and he couldn’t read his own code to sort it out. The app was gone in a week. The whole collapse came down to checks that lived in the design instead of on the server. Even the platforms slip on this: Base44 had a hole that let anyone create a verified account on a private company app, found by Wiz and patched inside a day.

The check: “For every protected page and every admin action, is the permission checked on the server, not just hidden in the design? Can a logged-out user, or a different logged-in user, reach someone else’s data by changing an ID in the address bar?” The test that catches it: log in as yourself, then change the ID in the URL to a different one. If you can see someone else’s stuff, that’s the hole.

4. Put a ceiling on the spend

AI tools and the services they plug into bill by usage, and by default there is no upper limit. Set one before you launch, not after the bill lands.

Two ways this hurts. The tool itself can run up a tab if you let an agent work unattended: one user posted a $607 Replit bill from a few days of building. And if a paid service is wired into your public app with no limit, a bot can hammer it all night, on your card.

The check, and this one is just settings: set a hard spending cap in your build tool today, around one and a half times what you expect to spend. On every paid service behind the app (OpenAI, Google, Stripe), set a usage cap and a billing alert. If you normally spend $5 a day, have it message you at $50. And move anything that costs money per use to the server, so the keys aren’t sitting in the browser. See step 2.

5. Name the usual security holes out loud

AI is good at fixing the standard security holes, and quiet about them until you name them. So name them.

There’s a well-known top-ten list of web security holes, kept by a group called OWASP. The AI will often leave a couple of them in by default, then patch them the moment you point at them by name. The clearest proof: a study by the firm Tenzai built the same app with five different AI tools, and all five left the same hole in place. It’s called SSRF, a way of tricking your server into fetching things it shouldn’t. Five out of five. Not because the tools are useless, but because none of them volunteer it.

There’s a newer one worth a mention too. AI sometimes “installs” software packages that don’t actually exist, inventing plausible names. Attackers have started registering those made-up names and loading them with malware, so a hallucinated part can quietly become a real one. Worth a quick check that the parts list is genuine.

The check: “Review this app against the OWASP top ten by name: SSRF on anything that fetches a URL, cross-site scripting on anything that shows user input, SQL injection on the database queries, and missing input checks. Then confirm every third-party package you’ve installed actually exists and is the real, official one.”

The one habit that beats any single check. Ask the tool itself where the vulnerabilities are. It wrote the code, it knows where the soft spots are, and it will tell you straight if you ask it straight. One wrinkle worth knowing: some of the newer models will refuse a request that sounds like an attack plan. That’s not a fault. It’s the same caution that stops someone else pointing an AI at your app, and occasionally it catches you asking about your own. Keep the question about finding and fixing rather than breaking in, and you’ll get what you need.

6. Keep the AI away from your live data

Never let an AI agent work directly on the database real people are using. Give it a copy to play in.

Agents do things you didn’t ask for. One deleted a company’s live database of more than a thousand records during a stretch when it had been told, in capital letters, to change nothing. That was Replit in mid-2025; the company refunded the user and added separation so an agent can’t reach the live database like that again. The lesson stands whatever tool you use.

The check: make sure there’s a separate “development” database from the “live” one, and the AI only ever touches development. Then confirm backups exist, and that a restore has actually been run once. A backup you’ve never tested is a guess, not a backup.

7. Make sure the world can actually find it

A lot of AI-built sites are invisible. Not to people, but to Google and to the AI assistants people now ask for recommendations. Thirty seconds will tell you which side you’re on.

Here’s why it happens. Many AI builders render the page inside the visitor’s browser, which means the raw page a search engine fetches is an empty shell. Google can sometimes work around that, slowly. But the AI crawlers, the ones behind ChatGPT, Claude and Perplexity, mostly don’t run the page at all. They read the raw version, and if it’s blank, you don’t exist to them. For a business that wants to be found or recommended, that’s the entire game lost, quietly, with no error to warn you.

The check: open your site, right-click, choose “View Page Source”. If you can see your actual words in there, you’re fine. If you see an empty box and a pile of script, your content is invisible. Ask your tool: “Switch this to server-side rendering or static generation so the content is in the raw HTML, and add page titles, descriptions and a sitemap.” Lovable added this for new projects in April 2026, so anything built before then still needs the switch.

8. Cover the basics if you collect personal data

The minute you collect someone’s details, even just an email, you’ve picked up legal duties, and “the AI built it” is not a defence. The basics are quick and you don’t need a lawyer for them.

In Australia the Privacy Act applies, and the regulator (the OAIC) picked up new enforcement powers and started checking businesses’ privacy policies in 2026. If you have any users in Europe or the UK, GDPR applies on top, and the fines there are real. None of that should stop you, it just means doing the obvious things.

The check: publish a plain-language privacy policy that says what you collect, why, and who else touches it. If you use cookie tracking, use a banner that genuinely stops the tracking when someone says no, or sidestep the whole thing with cookieless analytics like Plausible. Give people a way to delete their account and get a copy of their data. Add terms of use. And if you’re handling health, children’s or financial data, that’s the point to get proper advice, because those carry extra rules.

9. Check it on a phone

Open the thing on your actual phone before anyone else does. AI tends to build desktop-first, so menus and layouts that look perfect on your laptop fall apart on a phone, which is where most of your visitors are.

There’s no clever test for this one. Open it on your phone, tap around, try every button and form. The cracks show up fast: a menu that won’t open, text running off the edge, a “submit” button you can’t reach.

The check: open it on a phone, then hand the tool the fix. “Make this fully responsive with proper breakpoints, and make sure every menu and button works on touch, not just on hover.”

10. Keep a copy of your code somewhere you own

Make sure the code lives somewhere outside the tool that built it. Right now it may only exist inside the platform, and that’s a weak spot worth closing early.

Platforms like Lovable make it tempting to leave everything sitting inside their walls, where it’s easy but also limited: you can only do what the platform lets you do, and if its terms change, its prices jump, or it disappears, your app goes with it. Some tools hand you everything cleanly (Bolt, Lovable and v0 all sync to standard code and to GitHub), while others keep more of your app on their own infrastructure, and Base44 is the most locked-in of the popular ones. Either way, you want your own copy.

The check: connect the project to GitHub now, while it’s small, so a full copy of the code lives in an account you control. It’s free, it takes a few minutes, and it means the work is yours no matter what happens to the tool. Do it before the project gets big enough to be a tangle.

The honest call

Almost everything above, you can sort out yourself, today, by asking the same tool that built the app. It wrote the code, so it can review the code. The trick is what you ask it to do. Stop asking it only to build, and start asking it to tell you what you can’t see.

That’s the one move underneath all ten checks, and it’s worth more than any single item on the list. In a domain you don’t know well, and software is a deep one, the most valuable thing you can do is hand the AI your own blind spot on purpose. Something like: “I don’t understand software development well. This looks good to me and I’m about to put real users on it. What are the biggest risks here? What would keep you up at night? What are the things we have to fix that I have no way of knowing to ask about?” Then sit with the answer, because that’s the layer your own eyes were never going to reach.

There’s still one line where doing it yourself stops being enough. When you’re holding data that would genuinely hurt someone if it leaked, things like health records, money, or anything to do with kids, or when real revenue depends on the app staying up, that’s the point to get a one-off review from someone who builds this for a living. Not because you’ve done anything wrong, but because at that level you want a second set of eyes that already knows where to look. Same as you’d want a sparkie to sign off the wiring before you sell the house.

And if you’re nowhere near that line, if you’re building tools for yourself and a handful of people you know, then put the worry down and keep going. This is the best time there has ever been to build the thing that’s been stuck in your head, and the fact that you can now is not a trick or a fluke. It’s real. Ask the hard question, run the checks when other people show up, and until then, enjoy the part where it finally works.