Eight real vibe coding projects, read at the code level instead of shown as a screenshot. Every one is a working app that shipped, several with real signed-up or paying users behind them, and each was run through the same automated audit with the findings then verified against the code by a person.
The apps are named by category rather than by brand, and that is deliberate. Live products with real users cannot be named in public, which is the trade for reading real code instead of a demo. Two of the eight are mine.
Versions and advisories in this post were last re-checked on 5 August 2026.
What are examples of vibe coding?
Vibe coding examples are applications built mainly through natural-language prompts to an AI coding tool such as Lovable, Bolt, Replit, v0 or Base44, or to an AI coding agent like Claude Code or Cursor. The eight below are working codebases from a fixed 26-app audit cohort examined in June and July 2026. They include a browser-only music tool, two multi-tenant products, a command-line assistant, and two of my own production systems.
| What it was | What it does for a user | Who was using it | Built with | Historical score | A finding that changed the verdict |
|---|---|---|---|---|---|
| A public dashboard scoring code-repository health | Shows a health score for any open code repository, and plugs into CI | Anyone on the web, plus the teams that installed its CI action | Tool not disclosed. Public data only, plus a CI action shipped to users | 61 amber | Anyone can write chosen numbers into the cache every visitor sees |
| A client-side music-theory tool | Works out intervals and scales in the browser, no account needed | Anyone on the web, no account and nothing stored | Tool not disclosed. 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 | Helps a responder draft the timeline of an incident, with model help | Anyone with the link, no account, nothing kept between sessions | v0 by Vercel. No database, state in the browser | 57 red | Three paid-model routes accept anonymous requests with no rate limit |
| A command-line AI assistant | Turns plain English into shell commands and explains the ones that fail | Developers who installed it on their own machine | Tool not disclosed. Python CLI, local model by default | 56 red | A live provider key remained recoverable from git history |
| A public question-and-answer platform | Lets signed-up people post questions and answer each other | Real signed-up accounts, with donations taken through an external payment link | Tool not disclosed. 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 | Gives business customers one shared view of their operational numbers | Business customers it was sold to, several tenants in one table | Tool not disclosed. DynamoDB, hand-rolled auth | 43 red | Signing in required an email address and nothing else |
| My document-translation backend | Takes an uploaded document and returns it translated with the layout rebuilt | The translation product it runs behind | Tool not disclosed. Python, serverless GPU worker | 43 red | A crafted upload reads files off the server’s own disk |
| My admin panel for an XR product | Lets an internal team manage the content behind a Unity XR product | An internal team at the company behind the XR product | Tool not disclosed. Next.js, corporate single sign-on | 63 red | The pinned framework release carried a critical bypass affecting its middleware gate |
Two of the eight had money attached to the business behind them: the operations dashboard sold to business customers, and the question-and-answer platform, which took donations through an external payment link. Revenue changed nothing about what the code showed.
Each case below shows what the app did well, a finding that changed its verdict, and its score under the historical twelve-area method used for this fixed June to July 2026 study. These eight run from 43 to 76. All 26 apps in that cohort run from 29 to 81.
I selected this subset to show different app shapes and failure mechanisms. It is neither random nor representative of every vibe-coded app, and it cannot rank one coding tool against another. The scores document the historical research method; AxonBuild’s current review work does not promise a score out of 100. The audit engine is automated and the findings in the final reports were human-verified, because a scanner alert and a confirmed, reachable finding remain separate things.
What does a vibe coded app look like when you read the code?
Across these eight examples, visible features were usually more complete than the controls behind them. No reliability score exceeded 51 out of 100, while six apps scored 91 or better on secrets handling. That pattern belongs to this selected subset, not to every app built with AI.
8 real vibe coding examples, what each app does, and the best of the set
The eight span beginner through advanced builds. The beginner shape is the browser-only music tool: four dependencies, no login, no database, and the strongest build of the eight at 76. The intermediate shapes are the incident-timeline tool generated with v0 and the command-line assistant, both of which add a paid model but keep almost nothing stored. The advanced shapes are the multi-tenant B2B dashboard and my serverless translation backend, where several tenants, uploaded files and hand-rolled auth all meet. Examples seven and eight are my own vibe coding projects, in the section below. The best of the set on build quality are the music-theory tool at 76 and the code-quality dashboard at 61, where best means most finished rather than safe to ignore.
1. A code-quality dashboard that ships into other people’s pipelines (61, amber)
Built with: tool not disclosed. Stack is a public web dashboard plus a published CI action, no login anywhere.
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)
Built with: tool not disclosed. Stack is a browser-only front end with four dependencies, no backend and no login.
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 dependency pin. The rendering-framework version sat inside the affected range for a critical advisory in the server-component path. An Open Graph image route meant the deployment still ran a live App Router server, despite the app looking like a static client-side tool. 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. That image route is also the entire reachability trace: the advisory counted because a live server still answered on the affected path, not because a scanner matched a version string. Bumping only to the first release that fixed the remote-code-execution advisory still left a documented denial-of-service cluster on the same path, so this app needed a later minor release.
3. An incident-timeline tool with no database at all (57, red)
Built with: v0 by Vercel. Stack is browser state only, no database, plus three server routes calling a paid model.
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.
Its two critical findings were an anonymous paid-model surface and a reachable framework advisory. All three model routes accepted requests without authentication or a rate limit, so an unauthenticated script could spend the owner’s provider budget. The user-facing reliability bug was smaller but immediate: two of the three callers omitted the response.ok check present in the third. A failed request produced undefined state with no error boundary above it, and the in-progress timeline had no durable copy. Zod was installed but unused, so request bodies were not validated 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)
Built with: tool not disclosed. Stack is Python, packaged as a pip-installed command-line tool.
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 prompts on your machine unless you opt into a hosted provider.
The red verdict came from a live provider key that remained recoverable from git history after the project moved the value into an environment file. Deleting the current file did not revoke the credential; rotation was required.
The explanation feature added a separate reliability risk. It re-ran a failed command to capture output, and the installer wired that behavior into the shell prompt hook. A command that had an effect before returning non-zero could therefore run twice. The --execute path also used a confirmation prompt that defaulted to yes, so any response other than n ran the generated command.
5. A question-and-answer platform where three small findings met (48, red)
Built with: tool not disclosed. Stack is Supabase for the database, the auth and the row-level security policies.
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 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 page scripts could read it. A malicious question could therefore run code for each reader and capture sessions, including a moderator’s. The automated engine rated the chain medium; human verification escalated it to critical after tracing the three files together.
6. A B2B dashboard you could log into with an email address (43, red)
Built with: tool not disclosed. Stack is DynamoDB with hand-rolled authentication and federated cloud credentials.
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 sign-in action read an email address, looked the user up, and minted a full session. It required no password, emailed code, or magic link. Anyone who knew a customer’s work email could log in as that person, and the unsigned session cookie made the same boundary forgeable a second way. The form looked finished, which made the missing proof step particularly easy to overlook.
Two of my own apps, run through the same audit
The fixed cohort includes five of my own production apps, scored with the same method. Their scores ran from 36 to 63, and every one landed red. These two are from that set.
7. My document-translation backend, which trusts what you upload (43, red)
Built with: tool not disclosed. Stack is Python on a serverless GPU worker, behind signed cloud requests.
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 exposure.
8. My own admin panel, and its decorative front door (63, red)
Built with: tool not disclosed. Stack is Next.js with corporate single sign-on in front of it.
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 share two weak areas but fail in different ways. Seven scored under 45 on dependency hygiene, and the best reliability score in the set was 51 out of 100. Framework advisories recur in several cases, while the remaining verdict-changing findings span authentication, stored script execution, secrets, file parsing, abuse controls, and shared-data integrity.
In the fixed 21-app third-party cohort, reliability was the worst of twelve areas at 31.4 out of 100. Dependencies ranked second worst at 34.5 across the 20 apps where that area applied. At least 23 of all 26 apps had zero working automated tests, 17 of 21 third-party apps recorded errors nowhere a person would see them, and 12 of 14 third-party apps with an AI feature had a confirmed denial-of-wallet path. The full ledger with every denominator attached owns those aggregates. Why AI coding tools ship security holes by default examines one plausible mechanism without treating this cohort as proof of causation.
| What the demo showed | What the code showed |
|---|---|
| A login screen that redirects you when you sign out | Middleware that waves through any request carrying two query parameters |
| Row-level security switched on for every table | An insert policy reading WITH CHECK (true), with the session token in local storage |
| A B2B sign-in form asking for a work email | A session minted from that email alone, nothing else required |
| An upload that returns clean translated text | An XML parser that reads a file off the server’s disk if the document asks it to |
| A dashboard showing repository scores | A cache anyone on the internet can write chosen numbers into |
The stereotype about this category is leaked keys, and this subset points elsewhere. Six scored 91 or better on secrets and two hit 100. Across the 21 third-party apps, secrets averaged 84.4, the strongest of the twelve areas. The two examples here that scored 45 both had a real key written into a file and left recoverable.
Why did two of these apps score well and still land red?
Under the historical method, a score and a band answered different questions. The music-theory tool scored 76, the highest of the eight, and still landed red because the score estimated completion while the band recorded whether a confirmed critical was present.
Any confirmed critical forced red regardless of the aggregate score. The 76 carried one critical cleared by a version bump. The 61 had no critical and a longer completion list, making it the only amber here and one of four in the 26-app cohort. These research bands are historical evidence rather than a promise about any current work. Whether an AI-built app is ready to launch explains the practical launch decision without treating one number as a certificate.
How do you tell which of these examples your app resembles?
Four checks let you compare the most relevant trust boundaries in your own app with the examples above. They are triage steps, not proof that the rest of the app is safe. The dependency check comes from a fixed cohort finding: 9 of 26 apps ran a framework version with a published, reachable critical.
- 01 Make two accounts and try to read or change the first one’s data from the second. Use direct API calls as well as the interface, and restore any test data afterward.
- 02 Read the sign-in code and identify the exact proof required before it creates a session. The B2B dashboard required only an email address.
- 03 Find the framework version the deployed build actually uses, then check the vendor advisories and the fixed version. Re-test after updating instead of assuming the first patch clears every advisory.
- 04 Send a safe malformed request in a non-production environment: an unexpected field, a request with no session, or a harmless test file your app did not create. Confirm rejection, logging, and recovery.
Vibe coding project examples, by what they were built with
People searching for Lovable vibe coding examples, Claude Code examples or Replit examples want to see what one named tool builds. This set cannot answer that honestly. Seven of the eight builders chose not to be named, only the incident-timeline tool is on the record as a v0 by Vercel build, and 26 apps spread across many tools could not support a per-tool failure rate anyway.
What the code does support is a grouping by the kind of tool involved, because that is what decides which boundary work lands on you.
| Kind of tool | Named examples | What you end up holding | What to check first in it, based on this cohort |
|---|---|---|---|
| Prompt-to-app builders | Lovable, Base44, Bolt, Replit | A whole running app, with its database, its sign-in and its hosting wired up for you | Whether a second account can read the first account’s rows, tested through the API and not only through the interface |
| Interface generators | v0 by Vercel | Screens and route handlers you take away into your own project | Whether any route that calls a paid model answers an anonymous request, and what happens to the screen when one of those calls fails |
| Coding agents inside a codebase you already have | Claude Code, Cursor, Windsurf | Edits, features and files added to code that already exists | What was added that nobody asked for, and whether any credential ever written into the repository is still recoverable from its history |
| Visual builders | Bubble, FlutterFlow | An app assembled from components, with the platform holding the data | What you can export, and which parts stop working on the day you leave the platform |
The last column is the transferable part. None of it is an attribution: the eight examples were selected for variety of failure mechanism, not for tool coverage, and naming a builder from the code alone would be a guess. A gallery of projects sorted by tool is what most pages on this query offer, and it is the one thing a code-level read cannot supply.
Vibe coding example prompts, and what they produced
None of these repositories shipped its prompt history, so nothing below is a transcript. Each row pairs an instruction of the kind that produces a given feature with the pattern the finished code actually showed in this fixed 26-app cohort. The prompt is illustrative; the outcome is the evidence.
| The kind of instruction | What the finished code showed in this cohort |
|---|---|
| ”Add sign-in so people can only see their own data” | Row-level security written on every table in one app, and one insert policy reading WITH CHECK (true) that let an anonymous visitor start a chain ending in account takeover |
| ”Let businesses log in and see their own numbers” | A sign-in action that read an email address, looked the user up and minted a full session, with no password, emailed code or link required |
| ”Use AI to draft this part for the user” | Three model routes accepting anonymous requests with no rate limit, so an unauthenticated script could spend the owner’s provider budget |
| ”Let people upload a document and get it back translated” | A parser left on default settings that still resolved entities pointing at local paths, so a crafted upload read a file off the server’s own disk |
| ”Move my API key into an environment file instead” | The key gone from the current file and still readable in the project’s history, where deleting the file changes nothing and only rotation closes it |
| ”Make it faster” or “make it look better” | Strong scores on the visible areas, secrets at 91 or better in six of the eight, and no reliability score above 51 anywhere in the set |
The pattern is the same in every row. The instruction describes what a person will see, and the code deciding who is allowed to do it gets written by inference. An instruction that names the boundary out loud, such as only the owner of a row may change it, or reject a request with no session and record it somewhere, produces a first draft of that boundary, which is still a draft. In this set the feature code was rarely the part that failed.
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 anonymized case studies from a fixed June to July 2026 cohort, with human-verified findings attached. Their historical scores ran from 43 to 76. Across all 26 apps in that cohort, 22 carried at least one confirmed critical and none landed green. The selected eight and the wider cohort are descriptive samples, not population estimates.
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.
Which tools built the apps in this set?
Only one is on the record: the incident-timeline tool was generated with v0 by Vercel. The rest are anonymized along with their builders, so this post does not attribute any app to Lovable, Bolt, Replit, Base44, Cursor or Claude Code. With 26 apps and no platform holding more than a handful, the cohort could not support a defensible per-tool failure rate anyway.
Can a beginner realistically build one of these?
Yes, for the smaller shapes. The music-theory tool is about 2,300 lines with four dependencies, no login and no database, which is the kind of vibe coding project a beginner can finish and ship. The multi-tenant B2B dashboard, the file-parsing translation backend and anything with several tenants sharing one table are where the confirmed criticals in this set clustered.
Which vibe coding project ideas are realistic for a first build?
Pick something with no login, no database and nothing worth stealing. Browser-only tools, calculators and single-purpose utilities were the shapes that scored best here, because most of the failures in this set live at boundaries a small tool does not have: sign-in, tenant separation, uploads and paid model routes. The cost of the idea you pick is paid later, at the boundaries it forces you to build.
How do you turn a vibe coding sample into a production app?
Treat the sample app as a working draft and add the four things demos skip: a real proof step before a session is minted, tenant checks tested from a second account, a pinned dependency set you re-check against vendor advisories, and an error path that logs somewhere a person will look. In this set the code that failed was almost never the feature code. It was the boundary around it, which is also the part no screenshot shows.
What are the best vibe coding examples in this set?
By score, the music-theory tool at 76, then the admin panel at 63; by absence of a confirmed critical, the code-quality dashboard at 61. The music tool had strict types, honest N/A scores and 100 on secrets, and lost only on one dependency pin. The dashboard is the single app of the eight with no confirmed critical, which is why it is the only amber. Best here means most finished, not safe to ignore.
What is vibe coding and why is it bad?
Vibe coding is building software mainly by describing what you want to an AI tool instead of writing the code yourself, and it is not bad at producing a working app. What it was bad at in this research is the part no screenshot shows: 22 of the 26 audited apps carried at least one confirmed critical, at least 23 of the 26 had zero working automated tests, and no reliability score in the selected eight exceeded 51 out of 100.
The failures sat at the boundaries rather than in the features: who is allowed to do what, what happens when a request fails, and which version of the framework is actually deployed. That list is fixable, which is why bad is the wrong word for the method and the right word for shipping the result untouched.
What does vibe coded app mean?
A vibe coded app is one built mainly by describing the result to an AI tool, with the person accepting most of the generated code rather than reading it line by line. The term says nothing about quality on its own: the strongest build in this set scored 76 and the two weakest scored 43, and all eight were made the same way.
Read at the code level they share a signature rather than a standard. Visible features are more complete than the controls behind them, sign-in exists but proves less than it appears to, dependency versions drift, and errors are recorded somewhere nobody reads. The eight examples above are that signature in detail.
What are the top 3 vibe coding platforms?
No defensible top three comes out of this research, and any list claiming one is ranking marketing rather than code. The tools people mean by the question fall into three groups: Lovable, Base44, Bolt and Replit build a whole app from a prompt, v0 by Vercel generates interface code you take away, and Claude Code, Cursor and Windsurf work inside a codebase you already have.
With 26 apps and no platform holding more than a handful, this cohort cannot support a per-tool failure rate, let alone a ranking. Choose on what you will be left holding: whether you can export the code, whether the sign-in and data rules are yours to read, and whether the app runs anywhere other than the platform that made it.
Has anyone vibe coded a successful app?
Yes. Two of the eight had a real business behind them: an operations dashboard sold to business customers, and a public question-and-answer platform with real signed-up accounts and donations taken through an external payment link. Both shipped, both had users, and both scored in the 40s under the historical method used for this study.
Successful and finished are different questions. The dashboard minted a session from an email address alone, and the question-and-answer platform let an anonymous visitor post content that ran for every reader. Users arriving is not evidence that the boundaries hold.
Built it with AI. Can’t get the last part right?
That’s the normal state of an AI-built app, and it’s fixable. I trace what the app actually does, explain what needs changing, and build it if you want me to.
Talk about your app → 
Free 20-minute video call with me.