When does a vibe-coded app become a real product?

I’ve seen non-developers build apps that would have taken engineers days, if not weeks.

Not just functional apps, but polished apps with rich functionality that bring joy to users. They meet real needs, and the attention to detail is unmatched.

Product people and domain experts can build good apps, and they build them fast.

So the question is: when does a vibe-coded app become a real product?

That is the question a lot of companies are about to face.

In many businesses, engineers are no longer the only people building the next prototype. Client managers, sales teams, product people and domain experts build it too, using tools like Lovable, Base44, Claude and other AI app builders.

And that is a good thing.

A client explains a problem. A domain expert knows the workflow. They sit together and, instead of writing a long requirements document, they build something. In days, sometimes hours, not the six months a normal roadmap would take.

That moves the conversation from "tell me what you need" to "is this what you mean?"

Every layer in between is a chance to lose the point. A requirements document, a spec, a planning meeting, a handoff to someone who has never spoken to the customer: each one is where the original need turns into something slightly different. The person with the domain knowledge skips those layers. They are close to the customer, in direct contact, and they build what the two of them want.

Andrej Karpathy named the feeling when he coined the term in February 2025: "it's not really coding — I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works." That speed is intoxicating, and it closes deals that would have died in a six-month backlog.

Part of it is the hit of seeing the idea live. A working app you can click within minutes beats a slide or a spec, and that feeling separates the people who make things from the people who only talk about them. Give someone that hit once and they chase it again.

The instinct is not new. Tim Brown of IDEO has argued for years that you build a rough prototype to think with, and that it beats a thick stack of spec documents. Vibe coding makes that prototype cheaper to build than ever.

Make it work, make it right, make it fast

For years, engineers have said things like:

Make it work. Make it right. Make it fast. (I dug into how that maxim holds up once AI writes the first draft in Make It Work, Make It Right, Make It Fast in the Age of AI.)

Vibe-coded apps are brilliant at the first part. They turn a vague idea into something real that people can click, challenge, reject, improve and sell.

As an engineer, I value testing, linting, accessibility, observability, dependency management, secure deployments and maintainable code.

But I understand why a sales team does not want all of that on day one.

A prototype exists to move fast and to learn. It does not exist to look like a fully governed production system.

As Charity Majors puts it, "the true product of every (good) software engineering team is production." An app that works in the demo says nothing about month six, when the dependencies are stale, the API key has rotated, and someone files a support ticket.

When the prototype crosses a trust boundary

A prototype is scaffolding. It helps people see the shape of the thing quickly, test the idea, move around it, and decide whether it is worth building properly.

But you do not ask customers to live in the scaffolding.

Once the app carries the company logo, connects to real systems, stores customer data or has people depending on it, the business has moved from scaffolding to building, often without anyone deciding that shift has happened.

Someone has to own the foundations, the wiring, the fire exits and the maintenance. The same shift happens when the app starts costing money to run, when someone expects support, when the company's reputation rides on how good it is.

The specifics bite fast. A prototype humming along on someone's personal API key turns into a security and billing problem the moment it is business-critical. Exposed keys do real damage: one developer pushed AWS keys to GitHub, bots spun up servers to mine cryptocurrency within hours, and the bill climbed into four figures before he noticed. An app parked on a free Vercel Hobby plan breaks the rules as soon as it earns money: Vercel restricts that tier to "non-commercial personal use only" and pushes commercial projects onto a paid plan. The bill and the liability land on the company, not on the person who built it in an afternoon.

That is the moment the conversation has to change, because the app has crossed a trust boundary. Engineers are not trying to slow things down, and product people have not done anything wrong.

Before that point, it is experimentation. After it, it is software the business is responsible for.

This is where many companies will struggle.

Involve engineering too early and the process becomes the bottleneck vibe coding was meant to avoid. Involve engineering too late and the company inherits risk: security, accessibility, cost, operations, dependencies and support.

A graduation path

Banning vibe coding would be the wrong lesson. So would forcing every vibe-coded app through the same governance as a core banking system or a main customer platform, which kills the value that made it worth building.

What works is a graduation path: lightweight, visible, and clear to the people using it.

For example:

Level 0: Personal build — A live site, but no company data, no client access, no company brand and no production expectations. The API keys belong to the builder, not the business. It is hosted on Lovable or similar, not on company infrastructure.

Level 1: Company prototype — The company sees the value and wants real users to try it. Company branding may appear. Before it ships, someone reviews API key terms, hosting, data use and commercial restrictions. The app is still experimental, but it is no longer purely personal.

Level 2: Paid pilot — The app now needs paid usage above the free tiers, so it costs the company money. The business reviews and approves that spend. Costs are tracked, ownership is clear, and basic security, accessibility and dependency checks apply. Still no company APIs and no company login.

Level 3: Product — Uses real customer data, internal systems, company authentication or paid APIs. Now it enters the software development lifecycle.

A Level 3 app does not automatically need months of process. It means the business has accepted that this is no longer a demo but something the company owns.

The important part is not the exact labels. It is that someone can look at an app and quickly decide what level it is at, who owns it, and what has to happen before it moves up.

The handover problem

Moving an app up that path runs into a practical engineering problem.

If a team builds the app in Lovable and engineers then fix it directly in GitHub, where is the source of truth?

Is it the version in Lovable, or the version in the repository? Can the business team still iterate, or has the app moved into an engineering-owned lifecycle? The handover point decides who owns the next change.

Martin Fowler would call a fast prototype deliberate, prudent technical debt: you ship now and accept you will pay it back later. The trouble starts when that debt turns reckless and invisible, when the app drifts into production and nobody records that the handover happened.

Vibe coding does not remove the need for engineering judgement. Research by Advait Sarkar and Ian Drosos argues it redistributes that judgement toward managing context, evaluating output fast, and knowing when to drop the AI and edit by hand. The handover is where that judgement has to show up.

Do not kill the energy that built it

When the app graduates, remember why it exists. One person saw a problem, felt it, and built something. That vision and that drive are the reason you are here, not the engineering team and not the roadmap.

Most engineers, given the choice, want to build, not run product. Product thinking is its own craft. It takes discipline, customer context and a different set of instincts from engineering. The person who built the prototype may have those instincts because they were closest to the problem.

So the real risk at handover is human, not technical. Take the app away from the person who built it, tidy it up "properly", and you can drain the energy that made it good. Kill that energy and you kill the product.

Security and operations teams are part of that handover, but they cannot be the whole of it. Their job is to protect the business, keep systems stable and reduce surprises. That matters. But it is not the same as owning the customer problem or carrying the product vision. If the app becomes only a thing to secure, host, monitor and control, the company may make it safer while draining the reason it was worth saving.

The business needs to see this coming. The aim is to keep the initiator driving while engineering makes the thing safe to own, not to hand the whole thing over.

The tools are not the enemy

It would be easy to write these tools off as toys. They are not.

Take Lovable. It syncs two ways with GitHub, so the code can be cloned, edited in your own IDE, or self-hosted. It runs security checks too, from dependency audits to keeping API keys server-side. These builders are moving toward the enterprise problem, not away from it.

So the answer cannot be "stop using them". Platform guardrails are not the same as company ownership, and that is the line that matters.

A platform can generate the code, deploy it, scan it for obvious holes, and sync it to GitHub. It cannot decide whether the app now represents the company, whether a client treats it as an official product, who pays for the API usage, who gets paged when it breaks, or whether the business accepts the data and reputational risk. Those are company decisions.

This is not a new problem

Vibe coding is the AI-native version of something companies have wrestled with for years: citizen development. Low-code and no-code platforms made the same promise and hit the same wall. Microsoft warns that when security gets cumbersome, people bypass it and drift into "shadow IT". Gartner makes the point that low-code and no-code speed development but need support and governance so citizen developers can build safely at scale.

The useful framing comes from OWASP, whose Citizen Development Top 10 treats the goal as safe adoption rather than a ban: guardrails that let innovation thrive while keeping security intact. A graduation path is how you bring that spirit to vibe coding.

Engineering as enabler

Engineering's job here is to enable the people building these apps, not to guard a gate. I made the fuller case for that shift in From Gatekeeper to Enabler, where I argued that engineering adds more value handing citizen developers safe defaults than standing in their way.

There is a practical reason for this too. Every engineering team I have worked on is already at capacity. The roadmap is full, and no spare team is waiting to adopt a stack of vibe-coded apps. Much of what people are building is work that sat in the backlog for months, deferred behind something more urgent. Vibe coding gives those ideas another route to daylight. Funnelling every app through engineering is not feasible, so enablement is the only model that scales.

Give non-technical teams room to create: safe defaults, approved places to host, guidance on API keys, company accounts, data, branding and security, and a fast route to ask for help before the app becomes a liability. And give engineers the context to see why these apps matter.

There is a competitive point here too. If your company makes this too hard, the ideas will not wait. The people closest to the customer will find another way to build, or a competitor will get there first. One missed prototype does not matter much. Repeat the pattern, though, and you lose more than experiments. You lose innovation velocity.

In the AI era, the ability to turn customer insight into working software is becoming a first-class business utility. Security, operations and engineering should make that utility safe to use, not so hard to reach that people route around it. Make it hard and you do not stop the work. You push it into personal accounts, unmanaged tools, or the hands of a competitor who moves faster.

Vibe coding is already happening, so the question is not whether to allow it. The choice companies face is whether to treat it as shadow IT or to build a path where creativity, speed and engineering discipline work together.

Vibe-coded apps should not be blocked. They should be given a clear path, from a quick prototype to a product the company owns. The danger is not that people outside engineering are building software. The danger is that nobody knows when the business has become responsible for it.

Businesses still need to move fast. The trick is knowing when the thing built to learn has become something the company must own.