"Vibe Coding" Your Own Business App: What Can Go Wrong

What vibe coding is, and where it works well

The term describes building software by prompting an AI and accepting what it produces, judging the result by whether it seems to work rather than by reading the code. Tools like Lovable, Bolt.new and Replit generate a full app, including a database and hosting, from a chat. Coding assistants such as Cursor, Claude Code and GitHub Copilot do the same inside a developer's editor. Our comparison of AI coding assistants covers the main tools.

What typically goes wrong in AI-built apps

AI tools optimise for what you asked for. If you asked for "a member portal where clients see their invoices", you get screens that show invoices. You do not automatically get rules that stop client A from seeing client B's invoices. The common problems map closely to the OWASP Top 10 (2025), whose top two risks are broken access control and security misconfiguration.

This is not theoretical. CVE-2025-48757 describes an insufficient database row-level security policy in Lovable, through 15 April 2025, that let unauthenticated attackers read or write database tables of generated sites (NVD record). Lovable disputed it, stating that each customer is responsible for protecting their own app's data. Read that dispute carefully: whichever side you agree with, the platform's position is that the data is your problem.

The Singapore lesson: PDPC and AI-written code

Singapore has already had a data breach traced to AI-written code. In September 2026 the PDPC published a voluntary undertaking after an AI-generated bulk-email script exposed 95,364 customers' email addresses. The PDPC said the cause was the prompt and the missing review, not a fault in the AI tool. Our write-up of Singapore's first AI-related data breach covers the details.

Under the PDPA, your organisation must make reasonable security arrangements to protect personal data in its possession or control. Building the app with AI does not shift that duty to the tool vendor. If an AI-built portal leaks customer data, you may need to assess and notify the breach like any other, as explained in our guide to PDPA data breach notification. Past cases are on the PDPC enforcement decisions page.

Five risks to check in any vibe-coded app

1. Database access rules

Many app builders use a hosted database (often Supabase or Firebase) that the browser talks to directly with a public key. That design is only safe if access rules, such as Supabase row-level security, are switched on for every table and limit each user to their own rows. Ask the AI to list every table and its policy, then check them yourself.

2. Login and roles

Check that every page and API endpoint checks who the user is on the server, not only by hiding buttons. Admin functions need an admin role, and staff accounts need MFA.

3. Secret keys

Anything in front-end code can be read by anyone who opens the browser's developer tools. Secret keys for payments, email, AI APIs and databases must live on the server or in the platform's secrets store. If a secret was ever in the front end or a public repository, rotate it.

4. Personal data you do not need

AI tools happily add fields like NRIC, date of birth and full address. Collect only what the app needs. Under the PDPA, less data means less to protect and less to notify if something goes wrong.

5. Backups and ownership

Know where the database is hosted, who has admin access, how to export the data and code, and how to restore from a backup. If the builder's account is in one person's name, add a second admin.

Minimum review checklist before customer data goes in

Use this list before the first real customer signs up. Someone other than the person who prompted the app should run it.

If you cannot tick an item, or you do not know how to check it, treat the app as a prototype until someone who can read the code has reviewed it.

Vibe code, hire a developer, or both?

A sensible middle path is to vibe code the prototype yourself, use it to agree what the app should do, then have a developer review or rebuild the parts that touch personal data and payments. You keep the speed and pay for expertise only where it matters.

1. 1

   Prototype with no real data

   Build the screens and flows with dummy records. Show them to staff and a few customers.

2. 2

   Write down what it must do

   List users, roles, the data stored, integrations and what each role may see.

3. 3

   Get a security review

   Have the database rules, logins, keys and data flows checked before launch.

4. 4

   Fix or rebuild the risky parts

   Some apps need small fixes; others are cheaper to rebuild properly using the prototype as the brief.

5. 5

   Plan maintenance

   Libraries, platforms and AI-generated code need updates. Decide who patches and monitors the app.

For typical prices for a properly built tool, see our guide to custom software development costs in Singapore.

Do it yourself or get help?

If your app holds no personal data and only you use it, the checklist above is usually enough. Once customers, payments or staff records are involved, get a second pair of eyes before launch.

Our Security Health Check (S$290) reviews accounts, access and exposed services and flags the urgent fixes. For a tool built properly from your prototype, our Custom Tool or Dashboard package (from S$1,990) delivers code you own, with access controls, backups and a handover.