Vibe coding examples: what actually shipped, and what the evidence shows

Conceptual illustration, not a customer photograph.

Customer accounts from Lovable, Replit and Bolt describe AI-assisted internal tools and consumer releases. A separate interview examines internal adoption and the maintenance handoff. Read them for what was reportedly deployed, while keeping unmeasured outcomes separate from the claims about each product.

Use “vibe coding” carefully when reading examples

Conversational app builders can be used within a process that includes code review and testing. These cases are therefore examples of AI-assisted building; we cannot assume they involve accepting code without review, the narrower meaning of vibe coding. See the workflow comparison for how those approaches differ.

A demo shows that someone can demonstrate an interaction. A deployment account adds reported use, yet may say little about reliability, operating cost or maintenance. You can inspect a public app more directly than an internal one, but a short visit still cannot establish its security or performance.

Read each claim alongside the evidence it supplies. The linked public pages were checked on 23 October 2026 for these examples. No access to the companies' internal systems or financial records formed part of that review.

Atonom: a customer relationship management workflow

The Atonom story published by Lovable describes replacing a Salesforce contract with a custom CRM. It reports annual CRM costs falling from $40,000 to $1,200 for work involving sales, revenue operations and finance. The vendor publishes those numbers with customer attribution; we have not independently verified the savings.

That account concerns one reported internal workflow. Before treating it as relevant to your own CRM, examine integrations, access permissions, reporting requirements and support needs. The requirements of a simple sales process may differ substantially from those of a complex operation in a regulated setting.

List which parts of your existing workflow are necessary and which came with a platform designed for a much larger operation. Only then compare the current subscription with a replacement's visible hosting costs. The requirements determine what the replacement would actually need to do.

O3 World: resource planning built in-house

In Lovable's O3 World customer account, an in-house app replaces a resource-planning platform used by operations and finance. The page reports annual savings of $35,000. Treat this as a published customer report, not an independently audited comparison of total costs.

Resource planning involves shared records and recurring decisions, so generating a calendar is only part of the task. Establish who updates capacity and approves changes. Decide how people should proceed when the records they depend on disagree.

Before replacing a similar system, catalogue the reports and decisions people use. During the transition, retain a way to reconcile outputs from the old and new tools. Budget for migration and maintenance separately, even when the new licence bill looks appealing.

eXp Realty: a broader deployment claim

A hub connecting 83,000 agents and the launch of 26 country websites are reported in Lovable's eXp Realty story. These numbers describe the vendor's claimed deployment scope. They do not tell us concurrent usage, engineering work per site or independently measured reliability.

A large organisation already has users, knowledge of its operations and people handling deployment. Those starting conditions make this case different from a solo founder's prototype. Investigate them before assuming a small team could reproduce the result.

Separate reusable templates from market-specific work in your own comparison. Language, content ownership, access permissions and local processes can all shape a rollout despite a shared interface. The number of sites launched cannot, by itself, measure labour saved.

Bamboo Classroom: a teacher’s app built with Replit

Noni Ansari describes taking an interactive primary-learning app to the App Store in Replit's Bamboo Classroom interview. She reports 1,400 downloads overnight. The five-to-six-minute estimate concerns an early functioning app, not all the work required to publish it.

Here the builder is an individual creator releasing to consumers, unlike the internal-tool examples. The download count leaves retention and learning outcomes unknown. Consider instead what familiarity with a task might contribute to choosing a useful first product.

Frame My Home and Spellbound: consumer products built with Bolt

In its December 2025 profile of Simon Berg, Bolt describes two releases. Frame My Home turns pictures of homes or pets into framed art, with payments and outsourced fulfilment. Spellbound turns spelling lists into practice activities and uses subscriptions.

The vendor's descriptions establish reported releases, not revenue or reliability measured by us. They also leave business work beyond the app: fulfilment, customer support and distribution. Keep any reported partnership discussion separate from a signed distribution agreement.

Rokt: a separate interview adds the handoff question

An unnamed Replit customer at Rokt discusses dashboards, training tools and automations in a Sacra interview from September 2025. These are internal jobs that would not normally make an engineering roadmap. The interview also asks who will understand and maintain a tool once the person who built it leaves.

Sacra is a separate publisher presenting a first-hand interview, rather than a vendor's customer page. The source remains unnamed, and the account does not audit the full application portfolio. It supports an observation about adoption and handoff, without establishing that prototypes can replace Rokt's core product.

Compare the evidence before copying the outcome

Across these accounts there are three building platforms and a separate interview publisher. Selection limits what can be inferred: this is no representative sample. Look for a comparable workflow and operating environment before applying a reported outcome to your project.

Compare cases with the same evidence fields

• Product: identify the application or workflow as well as its building tool.
• Status: specify whether it is a demo, pilot, internal deployment or public release.
• Users: keep the intended audience, registrations and measured active use distinct.
• Outcome: preserve the metric, reporting period and attribution used by the source.
• Operations: find the maintenance owner and remaining dependencies.
• Unknowns: leave unanswered questions visible instead of inventing estimates.

Consistent fields make uneven evidence easier to compare. A selected vendor story can offer a lead for further research, but cannot tell you the typical success rate, average savings or how many other projects failed. Keep those limits beside the reported result.

Turn a relevant case into a small test of your own workflow. Before replacing a system people rely on, estimate its full cost, demonstrate recovery and examine access rules. Continue with the production checklist, ownership guide and small-team claims guide for those decisions.