What Can You Actually Build With Vibe Coding?

Vibe coding means describing the app you want in plain English and letting an AI model write the actual code, screens, and database behind it. You steer by intent, not by syntax. Andrej Karpathy named the practice in February 2025, writing that you 'fully give in to the vibes' and let the model handle the implementation.

That one-sentence version is deliberately short. The full origin story, IBM's formal definition, and how vibe coding differs from ordinary AI-assisted coding all live in What Is Vibe Coding and What Can It Actually Do?. This article picks up where that one leaves off: not what vibe coding is, but what you can actually build with it once you sit down and start prompting.

You can build a real, full-stack application: a working frontend, a backend, a database, and login all wired together from a written prompt, not just a clickable mockup. That covers internal tools, SaaS MVPs, dashboards, marketplaces, and consumer apps. The free tier caps how much you can build before you need a paid plan.

The building blocks stay the same across almost every AI app builder: a frontend interface, a backend API, a persistent database, and authentication so a user's data is actually theirs when they log back in. Add payments and you have something sellable, not just a demo. Joylo wires up all four of those pieces from a single prompt on every plan, including the $1 Trial, and meters how much you can build per month rather than which pieces you get access to.

In practice, the build categories people reach for most look like this:

• An internal ops tool a 5-person team uses to replace a shared spreadsheet.
• A solo founder's MVP dashboard for tracking the first 20 to 50 early customers.
• A two-sided marketplace prototype, listings on one side, buyers on the other, built to test demand before hiring a single developer.
• A subscription SaaS product with billing wired in from day one, ready to charge its first paying customer.
• A customer-facing portal for checking order status or account details, the kind of tool that used to take a small dev team a full quarter to ship.

The line between the free tier and a paid plan is almost always about capacity, AI credits and storage, not which features exist. A free plan can still ship a working database and login on the first prompt; it just runs out of build credits sooner than a paid one.

Complexity, not category, is where builders diverge. Lovable, Replit, and Base44 all name the same core range in their own documentation, SaaS products, dashboards, CRMs, and AI agents, but none of their docs claim to deliver a production-hardened complex system out of the box. That's why a multi-role marketplace or a payments-heavy app tends to need engineering review before launch, whichever builder you start with.

Most AI app builders generate responsive web apps first, and a responsive web app installed to a phone's home screen covers a large share of what people mean by 'a mobile app.' Fewer builders compile a native iOS or Android binary directly. If you need App Store distribution or device features like push notifications, verify that capability first.

The distinction matters because the two builds solve different problems. A responsive web app opens instantly in any browser, updates the moment you redeploy, and needs no app store review, which is why most vibe-coded MVPs start there. A native app buys you home-screen presence, offline access, and deeper device integration, at the cost of a separate build pipeline and a store review process an AI builder does not control. Joylo, like most AI app builders, ships the responsive web version; a true native App Store listing means wrapping that build in a separate native shell. The exact wrapping approach differs by vendor: Lovable ships a PWA or a Capacitor wrapper rather than React Native, Bolt builds through Expo to publish directly to both app stores, and Base44 packages a responsive web app into store-ready IPA and AAB files. Bolt's own documentation is blunt about the tradeoff: "Projects created for web do not easily switch over to mobile," so the mobile-or-web decision is worth locking in before the first prompt, not after.

If mobile distribution is the whole point of the product, for example a fitness app that needs step-count data from the phone's sensors, confirm a builder's native output before you commit a week of prompting to it. If the phone is just one more place people open the app, a responsive web build is usually the faster route to something real users can touch.

Yes. A marketing website, a landing page, or a full multi-page site with forms and a content section is well within what a prompt-driven builder handles today, and it's the fastest build type as long as the site stays state-free, with no complex data model behind it. The ceiling rises once you add e-commerce, user accounts, or custom booking logic.

A website and an app sit on the same technical spectrum, they just ask for different amounts of state. A brochure site is mostly static content: pages, images, a contact form. An app needs a database that remembers who a user is between visits, which is a heavier build even when it looks similarly simple on screen. The crossover is easy to miss: a five-page marketing site with a booking form starts crossing into app territory the moment it needs to remember who booked what, because that's exactly the kind of state a static site was never built to hold. Vibe coding handles both, but a five-page marketing site takes a fraction of the prompting a subscription product with logins and billing takes. Joylo builds either on the same plan ladder, starting from a $1 Trial, so a marketing site and a full SaaS product can start from the same account.

An AI app builder doesn't run one model for everything. It matches each sub-task, writing code, generating an image, structuring data, to the model built for that output type, then weighs that model's quality against its cost before routing the request. Microsoft's own architecture guidance recommends this multi-model routing for any multi-step agent workload.

Microsoft Learn's Azure Architecture Center lays out the same three-step logic any builder follows: match the model's output type to the task, weigh quality against cost, then test against real data before locking it in for production use. That is also the architecture behind Joylo's own build pipeline, which is powered by Claude Opus 4.8 for the reasoning-heavy steps of turning a prompt into working application code, rather than a single general-purpose model handling everything from copy to database schema.

For a non-technical founder, that architecture detail matters less than what it predicts about your own build: if your build is consistently weak on one task type, say the generated images look off while the underlying code, forms, and logic all work fine, that's usually a single-model routing gap, not a broken build. The model handling images is underperforming for that one job while the model handling your app's logic is doing its job correctly. The fix isn't to scrap the build or start over. It's to isolate the weak piece: re-prompt just that one part, source the asset elsewhere and drop it in, or flag it as a known gap and ship the rest. If instead everything is inconsistent at once, copy, layout, and logic all off together, that's a different signal, and it points toward the build needing a broader review rather than one more prompt.

Most real vibe-coded builds fall into two buckets: fast personal tools built by people who never intended to become developers, and platforms that scaled into real businesses. Emergent, a vibe coding platform, reached $100 million in annual recurring revenue eight months after launch, with its builders shipping more than 7 million applications.

TechCrunch's reporting on Emergent puts the platform at over 6 million builders across 190-plus countries, which is the clearest citable evidence that vibe coding produces real, used software at scale, not just demos. No institutionally verified list of specific named 'famous vibe-coded apps' exists yet, most roundups claiming otherwise trace back to vendor marketing rather than verified sources, so treat any specific consumer app you hear about as an illustrative anecdote, not a confirmed fact. The pattern that does hold up: a family meal-planning tool, a lunchbox-prep helper, or a five-person team's internal ops dashboard are the kind of builds that show up again and again, small, personal, and solving one real problem for the person who prompted it. For named, verified examples at the individual-builder level, see 5 Real Apps Built by People With No Coding Experience.

Vibe coding stops working at the point where speed stops mattering more than correctness, usually right as real users and real data show up. An academic study auditing 200 publicly deployed vibe-coded apps (arXiv 2606.23130, v3, September 2026) found 1,186 vulnerabilities, and 91 percent of the apps had at least one, with 65.77 percent of those vulnerabilities rated Critical or High severity.

The risk isn't only security. Research on vibe coding in practice describes a 'flow-debt tradeoff': the fast, frictionless-feeling build process accumulates architectural inconsistency and technical debt because there's no explicit design decision captured along the way, and speed keeps winning over review. MIT Technology Review adds that AI-generated code can look entirely plausible while not actually doing what it was designed to do.

IBM frames the security angle as categorically different from ordinary human-written-code risk. The specific failure modes are exposed secrets, hallucinated dependencies, and misconfigured APIs, the kind of gaps a skipped review never catches.

Veracode's 2026 GenAI Code Security Report found a 56 percent average security pass rate across the models it tested. Performance collapsed further on categories like cross-site scripting, the exact kind of vulnerability a rushed review is most likely to miss.

Georgia Tech's Vibe Security Radar tracks the same failure mode from a different angle: 74 confirmed cases of AI-introduced security vulnerabilities so far, 14 of them critical and 25 high risk, with March 2026 alone adding 35 more, more than all of 2025 combined.

This is exactly the gap Joylo's engineers get called in to close once a build has to survive more than its own demo. For the full decision framework on when to keep vibe coding and when to bring in a human, see Vibe Coding or Proper Development: When Each Wins, and for the security side specifically, Is Your AI-Generated App Secure Enough to Ship?

You close the gap between a working demo and a production app by adding the review step vibe coding skips: a structured audit of security, scalability, reliability, integrations, and code quality, plus a human who can fix what the audit flags. Joylo runs that audit, the AI Confidence Score, on every build, every plan, for free.

In a rescue pass, the audit tells an engineer where to look, but the pattern repeats often enough to state plainly: the first thing an engineer checks in a stalled vibe-coded build is usually the auth flow and the database migration path, the two places a fast, prompt-driven build tends to skip a step. Auth tends to break quietly, a session that never expires, a password reset that doesn't invalidate the old token, and it only shows up once a real user tries to abuse it. Migrations tend to break loudly but late, a schema change that worked fine against the demo's empty database locks up the moment real rows exist to migrate. Neither shows up in a working demo, because a demo has no adversarial user and no real data to migrate against. That's the actual gap between a build that works and a build that's production-ready: not more features, but the two places nobody stress-tests until someone else has to.

The audit catches what to fix; a named engineer is what actually fixes it. Joylo's own rescue-economy research quantifies which builders need that engineer most often: across a sample of repair listings, Lovable appeared in 53 percent, Replit in 45 percent, Bolt and Supabase at 29 percent each, Base44 at 24 percent, and v0 at 13 percent. See The Rescue Economy: What Breaks After You Ship a Vibe-Coded App for the full breakdown. Joylo's Expert Assist is a named in-house engineer who can see your codebase only once you approve access, a 24-hour first-response SLA, and a production-readiness check before you ship. On self-serve plans, that human review happens once you add Expert Assist, not automatically on every build; the five-domain AI Confidence Score audit is what runs by default from the $1 Trial up.

Once a build is live, keeping it that way is its own question, covered in How Do You Keep an AI-Generated Codebase Maintainable? And once you know what's buildable, the natural next question is which builder to use and what it costs, answered in Which AI App Builder Is Best, and What Does It Cost?