In February 2025, an off-hand tweet changed how software gets made. Andrej Karpathy, OpenAI co-founder and former head of AI at Tesla, described "a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." He later called it a "shower of thoughts throwaway tweet." It got 4.5 million views, became Collins Dictionary's Word of the Year, and started a real shift in who gets to build.
If you've vibe coded an app, you're part of that shift. You described what you wanted to a tool like Lovable, Bolt, Cursor, v0 or Replit, and a working product appeared. It runs. People can use it. And now you're staring at the screen with the question every founder reaches at this point: now what?
This guide is the honest answer. Not the demo-video version, the real one. Because the part you've just finished, building the thing, was the easy 70%. What comes next is the work that decides whether you have a product or just a clever prototype.
How big is vibe coding, really?
Vibe coding went from a meme to a serious way of shipping software in under a year, and the adoption numbers are hard to argue with.
A quarter of Y Combinator's Winter 2025 batch shipped codebases that were almost entirely AI generated, according to YC partner Jared Friedman. Cursor, the AI code editor, reportedly went from nothing to around two billion dollars in annual recurring revenue in roughly three years, one of the fastest climbs business software has seen. Lovable reached a hundred million in eight months. And Stack Overflow's 2025 developer survey found that 84% of developers now use or plan to use AI tools.
So if you built something with AI, you weren't cutting corners. You were using the same tools a serious slice of the startup world now runs on. The point of this guide isn't to talk you out of that. It's to show you what the tools quietly leave for you to finish.
The 70% problem: why your app feels almost done
Here's the honest answer, stated plainly. Vibe coding gets you most of the way to a product fast, but the final stretch is the hard part, and it's exactly the part a non engineer can't see.
That framing comes from Addy Osmani, who runs Chrome's developer experience at Google. He calls it the 70% problem. AI can rapidly produce most of the code for an app, he writes, but the remaining 30%, the edge cases, the integration with live systems, making sure your security and API keys are in a healthy place, can be just as time consuming as it ever was.
You've probably already met the doom loop he describes. You try to fix a bug, the AI suggests a change, and the fix breaks something else. You ask the AI to fix that, and it creates two more problems. Rinse, repeat. Sometimes it's five new problems.
It feels personal, like you're doing something wrong. You're not. It's structural. The AI writes code in big confident blocks without holding your whole app in its head, so it cheerfully fixes one corner while quietly breaking another.
The symptoms are always the same. The login that worked last week now spins forever. A feature you didn't touch is suddenly broken. An integration silently stops returning data and you've no way to diagnose why.
The technical debt you can't see
Underneath a working vibe coded app, there's usually a mess that doesn't show up until you try to build on it. Engineers call it technical debt, and AI generated code tends to pile it up fast.
GitClear analysed 211 million lines of code and found that copy pasted code has roughly quadrupled, and now outweighs reorganised, refactored code for the first time in their records. In plain terms, the AI keeps duplicating chunks instead of tidying them into reusable pieces.
That's the difference between a house built with proper foundations and one where every new room is propped up on the last. It stands up at first. Then you add a paying customer, and a feature, and another, and the whole thing starts to wobble.
This is why so many founders hit the same wall. The app that took a weekend to build takes months to make stable, because the speed that created it also created the debt. The fix isn't more prompting. It's someone who can see the structure, keep what works, and rebuild what doesn't.
None of this is a reason to regret building fast. The debt is the price of speed, and speed was the right trade when all you needed was proof the idea worked. The mistake is only in treating that first version as finished, and trying to pile real customers and new features on top of foundations that were never meant to carry them.
The risk that should worry you most: security
If your app touches user data, security is the part of that hidden 30% you cannot afford to leave to chance, because the consequences land on you, not the AI.
The evidence here is stark. Veracode tested more than a hundred AI models on over eighty coding tasks in 2025 and found that 45% of AI generated code contained a known, serious vulnerability. The detail that should stop you cold is that using a bigger, smarter model didn't improve the result.
This isn't theoretical. When researchers scanned 1,645 apps built on one popular vibe coding platform, 170 of them, more than one in ten, were leaking user data through a single missing setting: names, emails, addresses, payment details, even API keys. One viral app exposed 72,000 images, including government IDs, and over a million private messages, partly because keys were hardcoded and a database was left wide open. As Replit's own CEO put it, you can't expect novice developers to audit low level security configs.
The takeaway isn't fear, it's clarity. A security review is not a nice to have once real people start trusting your app with their data. It's the first thing that should happen before launch, not the thing you scramble to do after something goes wrong.
Prototype or product? Knowing where you actually are
The single most useful thing you can do right now is be honest about which of these you're holding. They're not the same, and confusing them is what sinks founders. A prototype proves the idea. A product survives real users. Here's the difference in practice:
If you've vibe coded an app, you almost certainly have the first one. That's not a criticism, it's the correct first step. Validating an idea with a prototype is exactly what these tools are for.
As Simon Willison, co-creator of the Django web framework, puts it: vibe coding is a fun way to explore what these models can do, and it's great for prototyping. But, he adds, vibe coding your way to a production codebase is clearly a terrible idea.
The skill that matters now isn't building faster. It's knowing what to keep, what to rebuild, and what to lock down before a real user, or a real attacker, finds the cracks.
What a technical review actually looks like
If the gap between prototype and product feels vague, here's how an experienced team makes it concrete. The first step is usually a short technical review, and you don't need to understand the code to follow what it produces.
A good review answers four practical questions:
The output is a plain-English map of what's solid, what's fragile, and what it'll take to close the distance. That map matters because it turns an overwhelming "is this salvageable?" into a clear set of choices. You learn what to keep, what to replace, and what to budget, before committing to a full build. It's the difference between guessing and deciding.
A working app still isn't a business
Even a hardened, scalable app doesn't guarantee anything, because the product was never the whole job. Distribution is.
CB Insights studied 431 failed startups and found the leading root cause wasn't running out of money. It was building something the market never properly adopted, a poor fit between product and demand. Running out of cash is usually the symptom, not the disease. "Build it and they will come" is the oldest lie in tech.
You may have already felt this one too. The app is live, the landing page you put together yourself is collecting a trickle of signups, and nothing is really moving. That's not a failure of the product.
It's the gap between having a thing and having a business: clear positioning, a marketing site that actually converts, and a real way to reach the people who need what you built. The founders who win pair a product that holds up under load with genuine distribution behind it.
Where Untapped comes in
This is the gap we close. We're not here to judge how you built it. Using AI to prove the idea was the right call, and it saved you a fortune. What we do is take the prototype you validated the idea with and turn it into something real.
In practice, that means three things. Through our software development service, we harden what you've built, closing the security holes and adding the authentication, testing and quality gates that stop features breaking each other. We rebuild the parts that can't be safely extended, so the app grows with you instead of cracking under you. And we build the features you can't vibe your way through, the integrations, the scale, and the polish that turn a clever demo into a product people pay for.
We've taken AI built prototypes through exactly this path, from fragile first version to something stable enough to launch and charge for. If you want to see how that looks in practice, our recent work shows the kind of products we help founders ship.
You did the hard part. You proved someone wants this. Let's make sure it survives success. If you've vibe coded something that's outgrown the vibes, get in touch and let's talk about what comes next.
Is vibe coding good enough to build a real product?
Vibe coding is excellent for proving an idea quickly and building a prototype, which is exactly what it's best at. For a product that real customers rely on, the AI generated code usually needs hardening, security work, and some parts rebuilt before it's production ready. Think of it as a brilliant first 70%, not the finished job.
Why does my AI built app keep breaking when I fix things?
Because AI tools tend to write code in large blocks without fully tracking how every part connects. When you ask for a fix, the AI can change one area and unintentionally break another, which is why one fix often creates several new problems. An experienced developer can restructure the code so changes stop having these side effects.
Is code written by AI secure?
Often not by default. Veracode's 2025 research found that 45% of AI generated code contained a known security vulnerability, and using a more advanced model didn't help. If your app handles any user data, a proper security review before launch is essential rather than optional.
What does it cost to take a vibe coded app to production?
It depends on how much of the existing code can be safely kept versus rebuilt, which is why a short technical review is the sensible first step. That review tells you what's solid, what's fragile, and roughly how much work the gap represents, so you can make an informed decision before committing to a full build.
Should I rebuild my app from scratch or fix what I have?
It's rarely all or nothing. Often the right answer is to keep the parts that work, rebuild the fragile foundations underneath, and add proper testing so the app stays stable as it grows. A technical review is the fastest way to find out which parts fall into which bucket.
I've built the app but no one's using it. What now?
That's usually a distribution problem, not a product one. A working app still needs clear positioning, a marketing site that converts, and a real way to reach the people who need it. Building the product is only half the job, getting it in front of the right audience is the other half.
Any thoughts?
Leave a comment