Aamir.melbourne
Start a project

Guide · Melbourne

Your vibe-coded app is live. It is not production ready.

Cursor, Lovable, Bolt and ChatGPT ship demos fast. Why AI-built apps fail security, privacy rules and first real users, and what to check before you take money.

Melbourne dusk skyline with abstract code fragments and a cracked shield, vibe-coded app production audit

The demo worked. That is not the same as production.

Vibe coding (prompting Cursor, Lovable, Bolt, v0, ChatGPT or Claude until something runs) is a real way to ship. Melbourne founders and operators do it every week. The trap is treating a working demo as a system you can take money on.

Production means strangers can use it, payments can fail safely, personal data is locked down, and you can change the thing next month without it exploding. Most AI-built apps skip that layer because the prompt never asked for it. If that is you, the vibe-coded app audit is the page that matches this situation.

Four failure modes I see on AI-built apps

  • You cannot explain the code. The model wrote auth, a database and a dashboard. You can click through the happy path. You cannot say what happens if two users share an ID, or if someone hits an API without a session.
  • Secrets leaked into the client. API keys, Firebase config that is too powerful, Stripe secret keys in a `.env` that got committed, or a public repo with yesterday’s token still valid.
  • Data rules are open. Firestore, Supabase or a homemade admin route lets any signed-in user (or any anonymous user) read other people’s rows. The UI hides the table. The API does not.
  • Privacy was never designed. Names, emails, location, uploaded files. No idea where they live, how long you keep them, or whether Australian Privacy Act or GDPR even apply. Cookie banners copied from a template do not fix that.

Australian rules, EU users, and what I will not pretend

If you collect information that identifies a person, Australian Privacy Principles usually apply to Australian businesses. If you have EU users, GDPR can apply even if you live in Melbourne. Other countries have their own rules. None of that is a vibe-coding prompt.

A technical audit can tell you what you store, who can read it, and which consent or cookie gaps are obvious. It cannot certify you as “GDPR compliant” or replace a lawyer. If someone sells you a stamp without looking at the data flows, treat that as marketing.

A short production-readiness check you can run today

  • Search the repo for keys. `sk_live`, `AIza`, `serviceAccount`, `SUPABASE_SERVICE`. If it is in client code or git history, rotate it.
  • Open the database rules. For Firebase or Supabase, ask: can a random user read another user’s documents? Test with a second account, not only your admin login.
  • Try the sad path. Wrong password, expired session, double-click pay, submit with empty fields. Note what the user sees and whether a duplicate charge or duplicate account appears.
  • List personal data. Every field you collect, where it is stored, who on the internet can query it. If you cannot list it, you are not ready for real users.
  • Confirm backups and a restore story. Hosting on Vercel plus a hobby database with no backup is a launch risk, not a cost saving.

Audit first, then fix (or rebuild)

A ranked list beats a panic rewrite. Many vibe-coded apps can be hardened: lock rules, move secrets, fix auth, patch the payment path. Some cannot: the architecture is a pile of conflicting patterns and a rebuild is cheaper than months of archaeology. That decision is the point of an audit, not a vibe.

If the urgent issue is a broken Stripe or form path, a workflow rescue may be the first slice. If you need a scoped attack-surface test with written findings, that is penetration testing. If the UI and bugs are the blocker, website fixes still apply. The audience page ties those together for people who shipped with AI and now need production.

When to get help

Bring someone in when you are about to take real payments, when a partner asked “are you compliant?”, when you found a key in the frontend, or when you are afraid to touch the repo. Send the live URL and what done looks like. I will say if an audit is the right first step, or if you should pause launch until the doors close.

  • I can name where personal data lives and who can read it.
  • A second test user cannot see the first user’s records.
  • Secrets are not in the browser bundle or a public repo.
  • Failed payments and failed logins do not create silent duplicates.