Why Vibe-Coded Apps Fail

Vibe coding is how a lot of founders now ship software. You describe the product in Cursor, Lovable, Bolt, v0, Replit, Copilot, or ChatGPT. The tool writes the app. A weekend later you have something that looks finished. Then a real user signs up, a card is charged, or someone in the EU asks where their data lives, and it becomes obvious the demo was not production-ready.

That is not a moral failing. The tools are good at interface and first-pass logic. They are weak at the unglamorous work that keeps an app safe once strangers use it. This guide explains what vibe-coded and AI-generated apps typically miss, which privacy rules follow your users (not your laptop), and what a production-readiness audit actually checks.

If you already have an app in the wild and you want it reviewed, start with our vibe coding audit. If you would rather rebuild with a scoped studio instead of patching generated code, see app development in Melbourne.

What vibe coding actually ships

A vibe-coded app is software generated mostly by an AI coding tool, directed in natural language, often by someone without a software background. The output can include a working login screen, a database, and a deploy to Vercel, Firebase, or Supabase. It can also include:

• API keys sitting in frontend code or committed .env files
• One shared admin account, or no real access control between users
• No tests, no error budget, and files nobody on the team can explain
• Personal information collected with no privacy notice, cookie policy, or deletion path

The product looks done because the happy path works on the founder's machine. Production-ready means the unhappy paths are handled too: a leaked key, a curious user changing an ID in the URL, a restore after a bad deploy, a regulator or insurer asking what you checked.

Security gaps that show up first

Most vibe-coded incidents we see are not Hollywood hacks. They are basics the model skipped because the prompt asked for features, not threats. The OWASP Top 10 is still the useful list: broken access control, injection, secrets, and misconfiguration.

Secrets in the repo or the browser

OpenAI, Stripe, Supabase, and Firebase keys pasted into client code so the demo could call an API. Anyone can open DevTools and take them. Rotation is messy because the key is copied through chat history, screenshots, and three hosting dashboards.

Auth without authorisation

Users can sign in, but row-level rules never landed. Changing /api/orders/12 to /api/orders/13 returns someone else's order. Storage buckets are public because that made image uploads easy.

Open admin and default passwords

A /admin route with no MFA. Staging indexed by Google. The same password the AI suggested in the first prompt, still live three months later.

A dedicated cyber security audit still matters for email, domain DNS, and devices. A vibe coding audit is the product-layer version of that work: the app itself, not only the mailbox.

Privacy rules follow your users, not your HQ

Founders often assume Australian Privacy Principles only apply to large companies, or that GDPR is an EU paperwork problem they can ignore from Melbourne. Collection is what matters. If people in the EU use the app, the GDPR can apply. UK users can trigger UK GDPR. Australian users can trigger the Privacy Act and APPs, with extra weight if you hold health or other sensitive information. The OAIC privacy guidance is the Australian starting point.

Vibe-coded apps commonly:

• Collect email, names, files, or chat logs with no lawful basis written down
• Send prompts and customer text to a third-party model with no processing terms
• Store data in a US region because that was the Firebase or Supabase default
• Have no deletion, export, or cookie story when someone asks

This is not legal advice and a studio audit is not a compliance certificate. It is a map of what you collect and where the gaps are. When the project is a new AI tool or a customer-data pipeline, a Privacy Impact Assessment is often the honest next step, not a privacy policy copied from another SaaS.

Technical debt and bugs that kill the next deploy

Generated codebases age in a particular way. The first version works. The fifth prompt to "just add Stripe" duplicates three checkout flows. Nobody wrote tests because the model did not volunteer them. The only person who can change a file is the person who still has the chat that created it.

Typical debt we rank in a vibe coding audit:

• Unowned files. Hundreds of components with no module boundaries. A one-line change breaks an unrelated page.
• No observability. When production errors, you find out from a user screenshot. There is no log drain, no uptime check, no backup restore test.
• Happy-path bugs. Race conditions on sign-up, double charges because webhooks are not idempotent, uploads that fail over 2 MB with no message.
• Hosting nobody owns. The Vercel project sits on a personal GitHub, a student Firebase plan, or a shared Lovable workspace you cannot export.

That debt is why "we will tidy it later" rarely happens. Later never has a model that remembers the architecture. Production-ready means a human can change the product without rolling a dice.

What a production-readiness audit covers

A vibe coding audit is a scoped review, quoted after a Discovery Session, not a public price list. We look at the repo and the infra together:

You get ranked findings in plain English and a quote to harden or rewrite the priority items. You approve each item before we change production. Melbourne-based, Australia-wide and international, remote by default.

Vibe-coded app FAQs

Is vibe coding the same as no-code?

Not quite. No-code tools hide the source behind a vendor. Vibe coding usually produces real source (React, Next.js, Flutter, and similar) that you theoretically own, generated by a model. Both can fail the same production tests. Vibe coding at least gives you a repo we can audit.

Can I just prompt the tool to "make it secure"?

You can try. Models will add middleware that looks serious and still miss row-level rules, secret rotation, and privacy notices. Security is a review against a threat model, not another feature request.

Do I need GDPR if I only have Australian customers?

Maybe not GDPR, but you may still have Australian Privacy Act and APP duties, especially if you handle health, financial, or children's data, or if you are not a small-business exemption case. If you later get EU users, GDPR can appear overnight. Map collection first. Guessing the regime second is how people get this wrong.

Should I rebuild or patch?

Whichever is cheaper and safer. A salvageable Next.js app with leaked keys and missing RLS can be hardened. A 40,000-line generated monolith with no tests is often cheaper to rebuild in stages. That call is the point of the audit.

Ready to get the app production-ready?

Book a free Discovery Session. We will confirm access needs and send a fixed quote before any vibe coding audit starts. Service detail: vibe coding audit.