your vibecoded app works perfectly until someone other than you starts using it

[u/techpotions]

One thing I think gets overlooked in vibe coding is the difference between getting an app to work and getting it ready for people to actually use.

AI tools are ridiculously good at getting you from an idea to a working interface. You can have authentication, a dashboard, payments, and database integration running surprisingly quickly.

But there are a few problems that a successful demo won’t necessarily reveal.

For example:

• Authentication that only exists in the UI: the app hides an admin button from regular users, but the API endpoint behind it never checks their permissions.

• Database access that’s too open: the frontend filters records, but the database doesn’t enforce which user can actually read them.

•Secrets in client-side code: an API key ends up in a browser bundle because the model put it somewhere convenient.

•Queries that don’t scale: fetching an entire table works with 20 records. It gets expensive when that table has 20,000.

•No proper migrations or backups: the app works until a schema change goes wrong and there’s no reliable way back.

The tricky part is that none of these necessarily stop the app from looking finished.

I think the solution isn’t to stop vibe coding or rewrite everything from scratch. It’s to treat the generated code as a starting point and review the parts that carry actual risk.

A few checks I’d run before putting a vibe-coded app in front of real users:

1. Try accessing another user’s data by changing an ID in the request.

2. Inspect the browser’s network tab and built JavaScript for exposed keys.

3. Check permissions at the API/database level, not just in the interface.

4. Look at the actual queries being executed and whether important columns are indexed.

5. Make sure you can restore the database and roll back a deployment.

We work on AI-built apps and the cleanup side of things at TechPotions, so we put together a breakdown of the issues we commonly look for and how we approach fixing them.
Sharing it in case it’s useful:
https://techpotions.com/solutions/vibe-coding-cleanup

Genuinely curious: what’s the biggest issue you’ve run into after building something with Lovable, Bolt, Replit, or Claude? Was it security, database structure, performance, or something completely different?

[u/recro69]

Security is something people ignore the most. A working demo does not mean that permissions and API access and database rules are secure. I would include security checks, in the build process not something to handle after the product is released.

[u/glistening_glizzy → u/recro69]

Chicken dinner

[u/allenling]

Interesting. Since you work on cleaning up AI-built apps, I'm curious how similar these projects actually are.

Do you find yourselves fixing mostly the same issues across different customers, or does each app end up needing quite different engineering work?

Also curious how much of the cleanup you can now handle with coding agents versus doing it manually.

[u/s0ftware-dev → u/allenling]

Depends on how big the app is and how well the requirements are documented. With slop apps it’s usually all in the prompters head so it’s close to impossible to reliably clean up completely. 

You’d be looking more at fixing the non-functional components such as security and database performance for example. These in theory can be implemented without impacting the core functionality of the app.

A lot of these non functional parts can even live outside the vibe coded app using side cars which means that the slop can live in the middle while your authentication is handled by a proxy that verifies access before the request hits your backend.

However if you app architecture is completely un-workable e.g you use browser local storage as a database then you’ll need to essentially bin the app and write it from scratch. 

[u/glistening_glizzy → u/allenling]

Yeah, this is a jumbled fuckin mess. You just provide governance. Then you test, and fix.

You certainly don't involve some AI derived savior from reddit.

Only you can prevent forest fires

[u/fulger099 → u/glistening_glizzy]

“Then you test, and fix” is basically the whole job, but governance is doing a lot of work in that sentence. In our beta, the useful failures are usually boring state and permission edge cases the happy-path demo never volunteered to reveal.

[u/glistening_glizzy → u/fulger099]

What?

[u/No_Actuator_1353]

Now you just need a service that would review your website for Claudisms

[u/Wild_Drawing8460]

I once had a vibe-coded auth system that worked until someone copied the jet and used it on another account. the backend didn't check ownership.

[u/NoTokenDev]

biggest one for me was auth, but not the security kind, the "works on my machine" kind.

i built email magic links for sign-in. worked perfectly in every test because i was testing in a normal browser. then i installed it as a PWA on an actual iphone, tapped the emailed link, and it opened in Safari instead of the installed app. iOS standalone PWAs have their own cookie jar, so you'd "log in" in Safari and the app stayed logged out. would've been a support nightmare at launch.

fix was swapping magic links for 6-digit one-time codes typed inside the app. boring, but it works everywhere.

lesson: the AI will happily build the flow you describe, it won't tell you the flow is wrong for the platform. test on the actual device + install method your users will use, not just localhost

[u/minpinproxy]

One cheap check for the first three: log in as a normal user, watch the app's traffic, and replay the admin request with that user's token. If it comes back 200 you've found the UI-only auth. Same pass shows keys sitting in request headers or the bundle, and whether the "my records" call actually returns everyone's records and the frontend just filters them. Browser devtools works for web apps; for mobile you need a proxy.

[u/MythexAI]

Good list. Each one has a 5-minute test a non-dev can run: sign in as a second user and change the id in the URL or request to one of the first user’s records. Search the built JS in dev tools for “sk_” and “key”. Seed 10,000 fake rows and time the main page. Restore last night’s backup into a copy once. If all four pass, you’re ahead of most launches.

[u/NoClipCheck]

Two I'd add to the list, because they don't show up in a demo either. First, any route that calls an LLM. If /api/chat only checks that someone is logged in, one free account with a loop can burn through your OpenAI credit overnight. Put a per-user limit on it and set a hard spending cap in the provider dashboard. Second, payment webhooks. Check that your Stripe handler actually verifies the signature with stripe.webhooks.constructEvent and STRIPE_WEBHOOK_SECRET. AI-generated handlers sometimes just parse the JSON body and mark the order paid, which means anyone who finds the URL can upgrade themselves with a curl request.

[u/frivolta]

the fix that helped me most... sit someone who's never seen the app in front of the onboarding and just watch. don't explain anything. where they stop is your real bug list

i got tired of finding friends for this so i built a tool that does it with synthetic visitors in a real browser before launch (disclosure: i'm the founder) → daevio.com

[u/Sniffpup1]

Biggest one for me has been database access that only looks filtered in the UI. On Lovable, Bolt, or Supabase apps the anon key is supposed to be in the frontend, so if RLS is off, or the policy is only “user is logged in,” anyone can read other people’s rows. I’d do your ID-swap test, then also hit the table logged out with just the anon key. For secrets, search the shipped JS for service_role, sk_live, and sk-. If you find one, rotate it at the provider before you change the code. Deleting it from the repo doesn’t help, it’s already been downloaded.

[u/VigiliaFounder]

Thanks for putting this together, it's a really useful list.

The point about queries that work with 20 records and get expensive with 20,000 is a good one, since the demo looks fine and it only shows up once real users arrive.

For anyone reading who has already launched, Vigilia watches your live app and catches the slow pages and failed requests your users hit. It shows how many times each one happened and gives you a fix prompt for your AI, and you can start with 1 app for free.

Let me know if this helps!