Can You Vibe Code a Production App? The Honest Ceiling
Vibe coding works great for some production apps and falls apart on others. Here's what actually holds up, where it breaks, and a pre-launch checklist before you ship to real users.
Short answer: yes, for a lot of what "production" actually means in practice. No, not for everything, and pretending otherwise is how people get burned. The honest answer depends entirely on what kind of production app you're building — its scale, its blast radius if something goes wrong, and how much of the "boring but critical" work you're willing to do yourself.
This isn't a hype piece and it isn't a takedown. It's a map of where vibe coding — describing what you want in plain language and having an AI agent write, run, and iterate on the actual code — genuinely gets you to a real, working, revenue-generating app, and where it starts to strain.
What genuinely works today
Indie SaaS with a handful of core features. A tool that does one or two things well — a scheduling app, a niche calculator, a content generator, a small B2B utility — is squarely in the zone where an AI agent can build the whole thing: database schema, auth, billing integration, frontend, deploy scripts. Thousands of people are running exactly this kind of app in production, charging real money, with the majority of the code written by an agent.
Internal tools. Dashboards, admin panels, internal Slack bots, reporting tools that only your team touches. The stakes are lower (a bug annoys your coworker, it doesn't take down a customer-facing service), and the requirements are usually well understood because you're the user. This is close to a best-case scenario for vibe coding.
Small business websites and simple e-commerce. Marketing sites, booking systems, catalog + checkout for a small shop. Well-trodden patterns, forgiving failure modes, and a lot of prior art for an agent to draw on.
MVPs validating an idea. If the goal is "does anyone want this," you don't need production-grade infrastructure — you need something real users can click through without it falling over during a demo. Vibe coding is arguably better here than traditional development, because speed to first user feedback matters more than architectural purity.
The common thread: single-tenant-ish complexity, moderate scale, and a failure mode that's annoying rather than catastrophic.
Connect the Claude or Codex you already pay for — the rest runs on workers that cost a fraction.
Download meshcode →Where it gets risky or breaks down
High-scale infrastructure. An agent can write a queue, a cache layer, a sharding strategy — but it's writing code, not carrying the scar tissue of having watched that system fall over at 3am under real load. Systems doing millions of requests a day, with tight latency budgets and cascading failure modes, need someone who understands the why behind the tradeoffs, not just working code that passes a smoke test.
Heavy compliance and regulatory systems. HIPAA, PCI-DSS, SOC 2, anything touching health records, payments infrastructure, or financial reporting. The code being "correct" is not the bar — the bar is a paper trail of decisions, audits, and controls that an agent has no visibility into and no accountability for. This is a domain where you need a human who understands the regulation, full stop.
Complex concurrent state at scale. Race conditions, distributed transactions, systems where correctness depends on the exact ordering of events across multiple services. This is genuinely hard for humans too — but an agent working from a plain-language description is especially likely to produce code that looks right, passes the tests it wrote, and still has a subtle bug that only shows up under real concurrent load.
If your app touches any of these, "vibe coded" shouldn't describe your production system as-is. It can still describe your prototype.
The middle ground: where most real launches actually live
Here's the part that gets lost in both the hype and the backlash: most apps aren't purely "easy" or purely "hard." You can get an agent to take you 80-90% of the way on almost anything — including systems with real scale and real stakes — and the last mile is where it matters whether someone (not necessarily a career engineer, but someone paying attention) is checking the work.
That last mile usually looks like:
- Security hardening — input validation, auth edge cases, rate limiting, secrets management. An agent will often get the happy path right and miss the adversarial path unless you specifically ask it to think like an attacker.
- Load testing — the app works fine with you as the only user. Does it work with 500 concurrent users? You won't know until you actually throw traffic at it.
- Edge cases — empty states, malformed input, timezone bugs, what happens when a payment webhook arrives twice. These are exactly the things that don't show up in a quick demo.
You don't need to be a 10-year backend engineer to close this gap. You need to be willing to ask "what happens if this fails," push the agent to handle it, and verify the answer yourself instead of taking the first working version at face value. Plenty of people are learning this by doing it — shipping, hitting a real bug, and closing the gap for next time. That's a legitimate path. It's just not the same as never checking at all.
Pre-launch checklist for a vibe-coded app
Before you point real users at it:
- Auth actually blocks what it should. Try logging in as one user and accessing another user's data directly by URL/ID.
- Secrets aren't in the repo or the client bundle. Grep for API keys before you push.
- Rate limiting exists on anything that costs you money per call (AI APIs, email sends, SMS).
- Payments handle retries and duplicates. Webhooks fire more than once in the real world — make sure double-charging isn't possible.
- Error states are handled, not just happy paths. What does the user see when the network fails, the API times out, the input is malformed?
- You've run it under some load, even informally — a script hitting your endpoints 50 times concurrently beats zero load testing.
- Backups exist for anything a user would be upset to lose.
- You (or someone) has actually read the auth and payment code, not just tested that it "worked once."
- Logging is on so that when something breaks in production, you can see what happened instead of guessing.
- You know your rollback plan if a deploy goes wrong.
None of this requires a computer science degree. It requires treating the checklist as non-optional, and being willing to ask the agent — and yourself — the uncomfortable "what if" questions before real users find the answers for you.
Vibe coding can absolutely get a production app in front of real users. Whether it should ship as-is depends on what's actually at stake if the last mile gets skipped.
👉 Download meshcode — Mac, Windows.