How to spot a vibe coded web app

What vibe coding means when it is an app, not a site

Vibe coding is describing what you want to an AI tool and letting it generate the product. Lovable, v0 and Cursor have made this fast enough that a working app can exist before lunch.

A website and a web app fail differently. A website presents information. An app holds state: people log in, enter data, change it, and expect to find it intact tomorrow. That brings permissions, validation, error handling and several people using the thing at once, none of which appear in a demo. An AI builds the path you described. The rest is discovered by whoever opens the app next.

We use AI every day and recommend it for prototypes. The problem starts when a generated prototype gets treated as a product.

Why the stakes are higher in an app

A weak website costs you an enquiry. A weak app costs you the work someone did inside it. A client loses twenty minutes of typing to a form that failed quietly, a booking is created twice, or two people overwrite each other, and nobody can tell which version is right.

If your app stores customer details, you also carry obligations under the GDPR, which has applied since May 2018. Those obligations sit with you, not with the tool that generated the code. Check the European Commission's data protection guidance if you are unsure what applies to your situation.

The interface tells

• No empty, loading or error states. The app looks right with demo data and blank with none, so a new user lands on an empty screen with nothing to do next.

• Actions with no feedback. You press Save, nothing visibly changes, so you press it again.

• Two components doing one job. Two date pickers, three button styles, dialogs that behave differently on each screen.

• Forms that lose your input. A validation error wipes the fields, or leaving the page discards everything without warning.

• Tables and dialogs that collapse on mobile. Wide tables overflow, modals sit half off screen, and the primary button is out of reach.

• Weak contrast in dense screens. Grey text on grey panels misses the 4.5 to 1 minimum in the WCAG contrast guidance, which matters more in software people stare at for hours.

The behaviour and data tells

• Validation only in the browser. The interface blocks bad input, the API accepts it, and the database fills with rubbish.

• Silent failures. A request fails and the screen carries on as though it worked.

• No undo and no confirmation. Delete removes the record immediately, with no archive and no way back.

• Stale data after an edit. You change a value and the list still shows the old one until you reload.

• Refresh and the back button break the view. State lives only in memory, so reloading a deep screen empties it or throws an error.

• Duplicates from a double click. One submit creates two records because nothing guards the second request.

The security and access tells

These are the ones worth paying someone to check before you invite real users.

• Permission checks in the front end only. The admin button is hidden, but the endpoint behind it answers anyone who calls it directly.

• Keys in client code. API keys and service credentials sit in the browser bundle, readable by anyone who opens developer tools.

• Every user effectively an admin. One role, one set of rights, no separation between your staff and your customers.

• No rate limiting. Login and password reset accept unlimited attempts.

• Uploads accepted without checks. Any file type, any size, dropped into a public bucket.

The OWASP Top 10 lists the categories these fall into, and it is a reasonable checklist to hand a developer.

Check your own app in ten minutes

None of this needs technical skill:

1. Submit your main form empty, then submit a valid one twice in quick succession. You want a clear error and a single record.

2. Turn off your wifi mid-action and see what the app tells you.

3. Refresh the page on a deep screen, then press the back button.

4. Open the app on your phone and complete one real task end to end.

5. Log in as a limited user, then type an admin URL straight into the address bar.

6. Run the main screen through Google's PageSpeed Insights and compare it against Core Web Vitals.

If three of those go wrong, the problems are structural rather than cosmetic.

What to do if your app shows these signs

Triage in three levels.

Surface problems, meaning states, feedback, contrast and mobile layout, are a focused design and front-end pass. Data and permission problems need an engineer to move validation and access control to the server, which takes longer but is not a rebuild. Foundations are the hard case: no real data model, no auth layer, no way to add a second type of user. There, a rebuild usually costs less than years of patching.

One honest note. Framer and Webflow, the tools we build in, are excellent for websites and the wrong choice for a real application. If your project needs accounts, roles and stored data, we will say so early rather than stretch a site builder to fit.

Written and last checked in September 2026. Rules and platform behaviour change, so verify anything time-sensitive before acting on it.