Every list of vibe coding examples I can find shows you the outside of the app: a screenshot, a line about the weekend it took, a link to go and try it. This one goes inside. I read the code of these eight vibe coded app examples line by line.
Each case gets four things. What it was, what the tool got right, the one finding that would have burned it at launch, and its readiness score out of 100. The eight run 43 to 76. All 26 apps in the corpus run 29 to 81, so these eight sit inside a wider range. Two of them are mine.
What are examples of vibe coding?
Vibe coding examples are working applications built by prompting an AI tool instead of writing the code by hand. The eight below are real ones, audited between June and July 2026 across twelve readiness areas, scoring 43 to 76 out of 100, each with its worst finding attached.
| What it was | Built with | Score | The finding that would have burned it |
|---|---|---|---|
| A public dashboard scoring code-repository health | Public data only, plus a CI action shipped to consumers | 61 amber | Anyone can write chosen numbers into the cache every visitor sees |
| A client-side music-theory tool | Four dependencies, no backend, no login | 76 red | The shipped framework version answers anonymous requests on a live remote-code-execution path |
| A security-incident timeline tool | v0 by Vercel, no database, state in the browser | 57 red | A failed model call leaves undefined state, and the in-progress timeline goes with it |
| A command-line AI assistant | Python CLI, local model by default | 56 red | It re-runs your failed command a second time to explain it, without asking |
| A public question-and-answer platform | Supabase, with RLS on every table | 48 red | Anonymous post, raw HTML render, token in local storage: account takeover |
| A multi-tenant B2B operations dashboard | DynamoDB, hand-rolled auth | 43 red | Signing in required an email address and nothing else |
| My document-translation backend | Python, serverless GPU worker | 43 red | A crafted upload reads files off the server’s own disk |
| My admin panel for an XR product | Next.js, corporate single sign-on | 63 red | Two query parameters walk straight past the login gate |
Every app is named by category only, the promise on the methodology behind these audits: nothing here traces a finding back to a team. The engine is automated and every finding human-verified against the code, so a loud scanner count and a real finding stay different numbers.
What does a vibe coded app look like when you read the code?
A vibe coded app, read at the code level, is usually competent wherever a screen exists and silent wherever none does. Across these eight, no reliability score cleared 51 out of 100, while six of them scored 91 or better on secrets handling.
1. A code-quality dashboard that ships into other people’s pipelines (61, amber)
A public dashboard that scores the health of open code repositories. It ships a second surface as well: a continuous-integration action that installs inside other people’s build pipelines.
Most of it holds up. Secrets scored 99, authentication 92, the handling around its AI-generated insights 92. Every piece of data is public and global, so authorization came back N/A instead of a zero, and this is the only app of the eight with no confirmed critical, which is why it is the only amber.
The write path into that global cache accepts attacker-chosen JSON with no authentication, no schema check and no rate limit, so one request rewrites the scores every visitor reads on the homepage. The gap gets wider in the CI action: the example workflows pin it to a mutable tag the release job force-pushes, and the action installs unpinned packages. A hijacked tag runs inside every installer’s pipeline, holding their secrets.
2. A client-side music-theory tool with nothing to steal (76, red)
A browser-only tool with no login, nothing stored, and not one outbound network call. About 2,300 lines, roughly 630 of them the interval maths the tool exists for.
It is the cleanest code of the eight: strict types, no escapes to any, a real README, and honest N/A scores on every area that did not apply. Secrets 100, input handling 99, performance 99.
It came back red on one line anyway. The rendering-framework version it pinned sat inside the window of a critical advisory in the server-side render path, and one image route keeps a real server listening there, which is easy to miss on something that looks like a static export. That gap between a static-looking build and a live server is the same one behind what a static host like Netlify does and does not check for you. The reachability trace behind that call is covered in full elsewhere. What nobody covers is the remedy: bumping to the release the advisory names leaves a documented denial-of-service cluster live on that same path, so the version that actually clears this app is a later minor. Even the one-line fix has a trap inside it.
3. An incident-timeline tool with no database at all (57, red)
Generated with v0 by Vercel, and built without persistence on purpose: each timeline lives in React state and browser storage while you work on it. Three routes call a paid model to help draft the write-up.
Keys were handled correctly and server-side, scoring 100 on secrets, and the data area scored 85, which is easier when almost nothing is stored.
The finding I keep thinking about is smaller than the two criticals and lands on a user sooner. Two of the three model callers omit the response.ok check the third one has. A failed request lands as undefined state with no error boundary above it, and since nothing is persisted anywhere, whatever was in the timeline at that moment is not recoverable. The person using it was, by definition, in the middle of an incident. Zod is installed and never imported once, so nothing validates the request bodies either. The open-endpoint half of this app sits in the twelve trust boundaries these apps failed at.
4. A command-line assistant that runs your failed command twice (56, red)
A Python command-line tool that turns plain English into shell commands and then explains the ones that fail. Installed with pip, running a local model by default, and the only developer tool in the 26.
The careful parts are careful. Data handling scored 91, performance 84, and the local-first default keeps everything on your machine unless you opt into a hosted provider.
The explanation feature is where it turns. Capturing a failure’s output means running the failure again, and the installer wires that into the shell’s prompt hook, so it fires on every non-zero exit without asking anyone first. A command that already had an effect before it errored gets that effect twice: the POST that came back 500 after the server had written the order, the migration that applied three of its five statements. The --execute path has the matching shape, a confirm prompt that defaults to yes and fails open, so anything other than typing n runs whatever the model produced.
5. A question-and-answer platform where three small findings met (48, red)
A public question-and-answer site on Supabase, with GitHub and email login and real signed-up users behind it.
Authentication scored 87 and secrets 99, and row-level security policies were written on every single table. The generator did the part everyone tells you to do.
Three findings, none alarming on its own, chained into anonymous account takeover. Anonymous visitors could insert questions, because the insert policy said WITH CHECK (true). That rich-text content rendered through dangerouslySetInnerHTML. The session token sat in local storage, where any script on the page can read it. Post one question carrying a script, wait, and collect the session of every reader who opens it, moderators included. None of the three looks like a vulnerability on the file where it lives, which is why no single-file review connects them: the engine rated the chain medium, and verification escalated it to critical.
6. A B2B dashboard you could log into with an email address (43, red)
An operations dashboard sold to business customers, several tenants sharing one table by design.
The code is better than most of what I read. Maintainability scored 83, secrets 91, and the cloud credentials are short-lived and federated rather than static keys pasted into a config file. The one model call is pinned to a version instead of floating on whatever shipped last.
The login is where it falls over: the sign-in action reads an email address, looks the user up, and mints a full session. It asks for no password, no emailed code and no magic link. Anyone who knows a customer’s work email, from a LinkedIn profile or the demo address printed on the page, logs in as them, and the unsigned session cookie underneath makes the same boundary forgeable a second way. The form stopped me, because it looked finished.
Two of my own apps, run through the same audit
I ran this audit against my own five production apps before pointing it at anyone else’s code. Their scores ran from 36 to 63, and red was the verdict on every one. These two are from that set.
7. My document-translation backend, which trusts what you upload (43, red)
A Python service that takes an uploaded document, parses it, translates it and rebuilds it, running as a serverless worker on rented GPUs.
The edge was done properly. Callers reach it through signed cloud requests with short-lived credentials rather than a shared API key, which is why authentication scored 84.
Then it trusts the file. Every DOCX and PPTX is a zip of XML, and the parser ran on default settings that still resolve entities pointing at local paths. A crafted header inside an uploaded document splices the contents of a file from the server’s own disk into the text that comes back as translation. There is no login on the parse endpoint, and the fix was one line, a hardened parser. In a helper script in the same repository, a live provider key sat in the code as a bearer token. My code, the exact mistake I write posts warning founders about. Deleting the file leaves that key working; only rotating it closes the account.
8. My own admin panel, and its decorative front door (63, red)
An admin panel for a Unity XR product, with corporate single sign-on and the CRUD screens an internal team needs. Authorization 81, input handling 77, data integrity 81, secrets 92, which adds up to the highest score in my own set.
The middleware file that redirects logged-out visitors to the login page lets any request carrying both a code and a state query parameter through untouched, and where it does check, it tests that a session cookie exists, never that it is valid. What saved it the day I read it is that the backend re-checks the token independently, which I had never designed as a backstop. Underneath that, the pinned framework release carries two publicly known criticals of its own, one of which walks past that middleware file without needing the query trick at all, and that pairing is what puts a 63 in the red band.
Six of these eight vibe coded apps scored 91 or better on keeping their secrets. Not one scored above 51 on whether anything would catch a mistake before a customer did.
What do these real vibe coded apps have in common?
These eight real vibe coded apps have the same two weak areas and eight different failures. Seven of the eight scored under 45 on dependency hygiene, the best reliability score in the set was 51 out of 100, and no two were burned by the same kind of finding.
Read enough vibe coded apps in production and the same two areas come last every time. Across the AxonBuild corpus, reliability was the worst of twelve areas at 31.4 over 21 third-party apps, and dependencies second worst at 34.5 over the 20 where it applied. At least 23 of the 26 had zero working automated tests, 17 of the 21 recorded errors nowhere a human would see them, and 12 of the 14 with an AI feature let a stranger burn the owner’s provider bill. The full ledger with every denominator attached is where those aggregates live, and why AI coding tools ship security holes by default is the mechanism a generator repeats every time.
The stereotype about this category is leaked keys, and these eight do not support it. Six scored 91 or better on secrets and two hit 100, against a corpus average of 84.4. Both of the failures, at 45 apiece, came the same way: a real key written into a file and left there.
Why did two of these apps score well and still land red?
A readiness score and a band answer different questions. The music-theory tool scored 76, the highest of the eight, and still landed red, because the score measures how much work a fix needs while the band measures whether a confirmed critical is present.
Any confirmed critical forces red whatever else scores well. That 76 carries one finding, cleared by a version bump. The 61 has no critical at all and a longer finish list, which makes it the only amber here and one of four across the 26. A founder asking whether they can launch on Thursday wants the band; a founder asking how many weeks of work this is wants the score. Whether an AI-built app is ready to launch walks the twelve areas both numbers come out of.
How do you tell which of these examples your app resembles?
Four checks place most apps against these eight in about ten minutes. Checks one and two catch the failure kinds behind two of the eight cases above. The third is one version number, and 9 of the 26 audited apps were shipping a vulnerable one. The fourth is a single deliberately malformed request.
- 01 Make two accounts and try to read or change the first one’s data from the second. That single test catches both the chained takeover on the Q&A platform and the workspace boundary on the B2B dashboard.
- 02 Read your own sign-in code and answer one question: what does it require before it hands back a session? The B2B dashboard required an email address, and the form looked complete.
- 03 Find the framework version your app actually ships and check whether anything in the project ever updates it. 9 of the 26 apps ran a version with a published, reachable critical, most of them one bump behind.
- 04 Send your app something it did not generate: a file it never created, a field the browser was not meant to set, a request with no session on it. That is where the code-quality dashboard, the Q&A platform and my translation backend each broke.
Those four are the compressed version of a much longer pass. The Beyond the Demo Audit is the long version, run over the same twelve areas every score above came from, with findings pinned to file and line. The scorecard estimates nine of the twelve from your own answers if you want the shorter read first.
Common questions about vibe coding examples
Are there case studies of vibe coded apps that failed a security audit in 2026?
Yes. The eight above are vibe coding case studies with their findings attached, audited June to July 2026 and scoring 43 to 76 out of 100. Across the wider corpus of 26 apps, 22 carried at least one confirmed critical and none came out green.
Have any vibe coded apps built on Supabase gone to production with real users?
Yes. The question-and-answer platform above was live with real signed-up accounts and scored 48 out of 100. Row-level security was on for every table it had, and one insert policy reading WITH CHECK (true) was the first link in a chain ending in anonymous account takeover.
What went wrong in real vibe coded apps built with v0 or Base44?
The v0-origin build in this set is the incident-timeline tool at 57 out of 100, and its failure was ordinary. Two of three model callers skipped a response check, no error boundary sat above them, and with no database anywhere, a white screen destroyed the timeline being written. What a platform like Base44 certifies about itself is a separate question from what your own app’s code does.
Did any of these vibe coding examples come out clean?
No. The best of the eight, at 76, still carried one reachable critical, and the only amber, at 61, is amber because it had no confirmed critical rather than because it was finished. Across all 26 audited apps, four landed amber and zero landed green.
Don't guess where you stand.
The free 2-minute Beyond the Demo Scorecard estimates where you stand across 12 readiness areas and shows what to check first.
