Something genuinely new happened
A person who has never written code can now describe an app to an AI and watch a working version appear. Not a mockup: a running thing, with screens and buttons and data. A weekend of prompting now produces what used to take weeks and a hired developer.
This article is not going to tell you that is bad. It is genuinely new, and as a way to make an idea tangible it is the best tool that has ever existed. The article is about a narrower question: what that running demo contains, what it does not, and how to tell whether it is ready for real users.
You own code you cannot read
Here is the uncomfortable core of vibe coding: the AI wrote the code, you accepted it, and nobody involved understands it. While everything works, that distinction is invisible.
Software, though, breaks. When it does, fixing it requires exactly the understanding that got skipped. You can ask the AI to fix the bug, and it will confidently rewrite things you cannot evaluate, and you have no way to tell a fix from a fresh bug in different clothes. You have become the maintainer of a codebase that has no maintainer.
This is the single deepest difference between a generated demo and professional work. It is not that a studio types better code. It is that afterwards, someone understands what exists and why.
An app is an iceberg
What you see on your laptop is the visible tenth: screens, buttons, data that appears when you click. What a real product needs is the mass under the waterline. Hosting that stays up when your laptop is closed. A domain with TLS certificates that renew themselves. A real database with backups you have actually tested, and migrations for the day the data model changes. Secrets and API keys stored somewhere that is not the source code. An email provider that gets your messages past spam filters. Monitoring that tells you the app broke before your users do.
None of this appears in the window where you prompted the app into existence, and none of it is optional once strangers trust you with their data. Most of it is invisible right up until the first real user shows up, which is the worst possible moment to discover it.
Deploy is a process, not a button
"It runs on my machine" and "it is shipped" are separated by an entire discipline. Real products run in environments: the version you experiment on, a staging copy where changes are checked, and production, which users see. Changes travel between them through a pipeline that builds the app the same way every time and runs checks before anything goes live. And when a release goes wrong, and eventually one will, you roll back to the previous version in minutes, because the pipeline kept it.
When we build, that pipeline exists from week one, before the product is feature-complete: on ChildLink, our own app, every build that ever reached an app store went through the same CI pipeline, which is why launch week was routine. A project generated in a single chat window has none of this, and nothing in the prompting experience ever suggests it should.
Security is where it gets expensive
Generated apps tend to share a family of quiet problems: API keys pasted where the browser can see them, missing authorization checks so that any logged-in user can request any other user's data, no rate limiting in front of endpoints that cost money per call, personal data written into logs in plain text. Not because the AI is careless, but because nobody asked, and nobody was there to check.
The stakes are not theoretical. The moment real people put real data into the app, GDPR applies to you, whether or not you understand your own stack. "I did not know what the code did" is not a sentence you want to say to a user whose data leaked, or to a regulator.
Software rots
Even untouched, software decays. Dependencies get deprecated, third-party APIs change shape, model versions are retired, app stores raise their minimum requirements. A living product needs someone who notices these things and responds before users feel them.
The vibe-coded app has no one on call. That is the practical question hiding under all the technical ones: not whether the app will need maintenance, but who is doing it, and whether they will understand what they are looking at.
When vibe coding is exactly the right move
Validation. Prototypes. Internal tools where the blast radius of failure is one annoyed colleague. Learning what you actually want by building three wrong versions in a weekend. For all of these, AI-assisted building is not a compromise, it is simply the best option.
And here is the part we mean sincerely: the best product brief a studio can receive is a founder's working prototype. It communicates the idea better than any specification document, because it shows what you meant instead of describing it. Vibe-code the prototype. Just do not confuse it with the product.
The middle path: your prototype, professionally rebuilt
The choice is not "keep prompting alone" versus "throw it away and pay for a mystery". The productive path runs through the middle: bring the prototype, and let a scoping pass turn it into a written plan with a fixed scope, a fixed price, and a timeline.
What a professional build adds is precisely the iceberg: infrastructure that stays up, a deploy pipeline with staging and rollbacks, security that has been checked rather than hoped for, monitoring, documentation, and full IP transfer, so the code is yours and understood. A window of post-launch fixes and an optional care plan answer the "who is on call" question that the prototype never could.
You keep the thing you were always best at: understanding the product. Now somebody also understands the code.
Five questions before you ship it
Could you fix it if it broke on a Sunday? Where do your API keys and secrets live, and who can see them? What happens to your users' personal data, and could you answer a deletion request tomorrow? How does a change travel from your machine to your users, and how does it travel back out if it breaks something? Who updates the app in six months when a dependency it stands on is retired?
If those answers exist, ship it, sincerely. If they do not, what you have is a prototype, and a good one: it already did its job of proving the idea. The next job, turning it into a product, is a different kind of work, and it is exactly the kind that is worth handing to people who do it every week.