You are looking at an app you or your team has just vibe coded. You love it. It solves a real business problem and it could be a game changer for the business. But what next? Can it be trusted?
I get this question a lot, and the answer is yes. Vibe coded software can be as safe as or safer than anything else on the market, and you can absolutely commercialise it and make it something your core business leverages or relies on. It just has to stop being a vibe coded app and become an AI-Managed App.
The difference is not who wrote the code. It is whether anything is looking after it.
The short answer
Yes, but not without a little extra work. Equally, it doesn't mean handing it to a developer to rewrite by hand over several months at a cost of thousands of dollars.
What is an AI-Managed App?
An AI-Managed App is software that is built by AI, secured by AI, and owned by a human.
That is a different thing from both of the options people usually think they are choosing between.
- A vibe coded app. AI built it. Nobody secures it and nobody owns it. It is fast and it demos beautifully, and it is one exposed endpoint away from a very bad week.
- Developer-led software. Humans built it and humans maintain it. It is the traditional answer, and it is slower, more expensive, and no safer. Human-written code has always shipped with vulnerabilities. The difference is you waited three months for them.
- An AI-Managed App. AI builds it at machine speed. AI guards it at machine speed, testing continuously instead of once. A human owns the architecture, the money-and-data paths, and the outcome.
The mistake is treating "vibe coded" and "real software" as the two ends of a scale, where safety is something you buy back by adding humans and removing AI. That is not the trade. Adding humans to review every line is slow and, for the failure modes AI actually has, not even particularly effective. What makes software safe is not the absence of AI. It is the presence of a process and an owner.
So the goal is not to graduate out of AI. It is to stop being unmanaged.
How to secure and commercialise your vibe coded app, step by step
So you described an idea to Replit, Lovable, Cursor or Claude, and a working app came out the other side. That is a genuine achievement. Two years ago it would have taken a team and a few months.
But there is an uncomfortable second act. The thing that makes vibe coding brilliant for prototyping, which is speed without needing to understand the code, is the same thing that makes it risky the moment you take payments and store customer data.
The numbers are not subtle. When Veracode tested AI-generated code across a large set of models, roughly 45% of samples introduced a known security flaw, and that pass rate has not improved across testing cycles even as the models got better at writing working code. When researchers at Escape scanned around 5,600 live, publicly deployed vibe coded apps, they found more than 2,000 high-impact vulnerabilities and 400 exposed secrets. That is roughly one in three apps shipping with a serious hole in it.
So this is not an argument against vibe coding. It is an argument for knowing what to do next.
First, understand the demo is not the product
A demo has one job: prove the idea works. A product has a much harder job. It has to work when the user is new, confused, on a bad connection, entering rubbish data, paying real money, or deliberately poking at it.
AI coding tools are optimised for the first job, not the second. They write the happy path because that is what you described. The result looks finished long before it is safe. The code runs, the feature works, and the vulnerability sits quietly in production until someone finds it.
The mistake is thinking that because the app works once, it is ready for everyone. Everything below is about removing that gap. The first three steps shrink what you have to secure. The rest test and defend what remains.
And to be clear about the spirit of this: I am not here to tell you to eat your vegetables. This is not about taking the fun and the speed out of vibe coding, and you should absolutely move from prototype to product with the same urgency you moved from idea to prototype. AI coding is here to stay. We just need to talk about the next steps.
1. Cut the surface area
AI makes features feel free. You ask for a dashboard and get one in minutes, so you keep going: exports, filters, team management, notifications, a settings page. The app looks richer, and the surface you now have to defend just doubled.
Before you go live, write down the smallest version that must work end to end. Everything outside that list is not launch scope. Fewer features means fewer endpoints, fewer inputs, and fewer ways in. This is the cheapest security work you will ever do, and you do it by deleting, not building.
2. Use services for the critical stuff
This is the single most important habit. Do not let AI write your own authentication, session handling, or card processing. Hand those to specialists whose entire business is getting them right.
- Payments to Stripe. When card details go straight to Stripe rather than through your servers, you never touch raw card data, and your PCI compliance obligation shrinks to the simplest tier. Stripe is audited against the full standard every year so you do not have to be.
- Logins and identity to a service like Clerk or Auth0. Authentication is one of the most common places vibe coded apps break, and it is the last place you want a homemade version.
- Hosting, secrets and deployment to a managed platform like Replit or your cloud provider's own tools.
Every one of these is a whole class of bug you now cannot write, because you did not write the code. You are standing on infrastructure that is tested harder than anything a small team could build.
3. Get the architecture right, even if that means starting again
One feature of the vibe coding method is massive refinement and change. You start with something, and after all the demos, the feedback and the exploration, the product is completely different. That is great. That is the purpose of the process.
But once you can see the product, and you know how it should look, feel and function, start again.
That sounds like heresy when the whole appeal was speed. It is not. The first build was never the product. It was the fastest way anyone has ever invented to work out what the product should be. The knowledge is the valuable output, not the code. And the rebuild is fast, because you are no longer discovering what you want. You are describing something you finally understand, to a tool that builds at machine speed. What took three weeks of exploration takes days when you already know the answer.
The second build is where architecture gets designed instead of accumulated. In the first build, the data model grows out of the interface: a table here because a screen needed it, a field there to make a demo work. Nobody decided the structure. It accreted. Start again and the schema can match the product, because you now know what the product is.
Three things to get right the second time.
- Know the difference between authentication and authorisation. Authentication asks "who is this?". Authorisation asks "what are they allowed to do?". Vibe coded apps constantly confuse the two: they check that someone is logged in, then assume the rest is fine.
- Enforce it at the data layer, not the interface. Every important action must be safe even if someone calls your API directly, rather than going through your nice front end. If the only thing stopping a user is that the button is hidden, nothing is stopping them.
- Isolate tenants from the first commit. For anything multi-tenant, the dangerous bug is not "someone can log in". It is "someone can read another company's data". That needs proper row-level rules in the database, designed in, not bolted on.
This is exactly the class of mistake that exposed around 1.5 million access tokens in the widely reported Moltbook breach: a misconfigured database rule, in an app whose founder proudly noted he had not written a single line of code. Retrofitting these boundaries later is painful and easy to get wrong, which is the whole argument for the second build.
Do steps 1 to 3 and the amount of code that genuinely needs a careful human eye drops dramatically. That is the goal.
4. Test what is left, continuously, not once
Here is where I part ways with the standard advice. Almost everyone says the answer is "mandate human review of all AI-generated code". Human judgement matters, but a person reading every line is slow, it does not scale, and it is not even that reliable for the boring, repetitive vulnerability classes that AI code fails on.
AI writes code at machine speed. Your security checking has to run at machine speed too. So point AI at the problem: automated security testing and AI pen testing that runs continuously over the codebase, not a single review before launch. Static analysis for code-level flaws. Dependency scanning for the libraries. Continuous checks that actively try to break the running app.
Save the expensive human attention for the two things machines are worst at: the architecture decisions, and the handful of critical boundaries where money and personal data live. Route the attention. Let AI do the exhaustive line-by-line filtering, and have a person review the findings and own the design. That is not lighter security. It is security aimed where it counts.
One more reason to test continuously rather than once: iteration makes it worse, not better. A controlled study found roughly a 37.6% increase in critical vulnerabilities after just five rounds of AI-assisted refinement. Asking the AI to "fix it" does not reliably fix it. It often adds new problems while you are not looking.
5. Give the AI better workflows, not just better prompts
The generic, out-of-the-box agent is the floor, not the ceiling. Left to its defaults, an AI coding tool starts every session from zero: no memory of your standards, no knowledge of your architecture decisions, and the same happy-path habits that created the risk in the first place.
The teams getting consistently safe output do something different. They codify how they work into skills and workflows the AI follows every time: how secrets are handled, which services own auth and payments, what a change must pass before it ships, how a security check runs before anything merges. Most serious AI coding tools now support this directly through reusable skills, project instructions and defined workflows.
Then they refine the process. Every time a review catches a mistake, the fix goes back into the workflow so the same mistake cannot happen twice. The generic agent makes the same errors forever. A refined workflow means every session starts from your standards and gets better as you learn.
This is the difference between using AI and operating it. The prompt gets you a feature. The workflow gets you a repeatable, improving process that happens to be fast.
6. Patch fast, and make change safe
The apps that stay secure are not the ones that were perfect at launch. They are the ones that can fix a problem quickly and change without breaking themselves.
Two habits do most of the work here.
- Put a basic automated pipeline in place so every change is checked before it reaches users: does it still build, do the critical paths still work, did anything obvious just break. It does not need to be fancy. It needs to catch the regression before your customer does.
- Keep changes small and deliberate. Big, sweeping AI edits are where new holes appear. Small controlled changes with a check on each one are how you keep the speed of vibe coding without the fragility.
Fast patching plus a safety net is what lets you keep moving. Without it, every new feature is a gamble with your existing security.
7. Handle the three things people forget
Beyond the obvious, three newer risks catch out vibe coded products specifically.
- Secrets. Hardcoded API keys and credentials are the most common failure of all. Get every secret out of the code and out of your version history, into proper environment variables, and rotate anything that has ever been committed. Assume any key that touched a repo is already compromised.
- Invented dependencies. AI models hallucinate packages that do not exist. About one in five AI-generated samples references a package name that is not real, and attackers now register those predictable fake names with malicious code inside, waiting for someone's AI to tell them to install it. Pin your dependencies, lock your versions, and check that a package is real and maintained before it goes anywhere near production.
- The tools themselves. The AI coding agents and their connectors are now an attack surface in their own right. Hidden instructions inside a README or an issue can redirect what an agent does. If you are wiring up connected tools and agents, treat that plumbing with the same care as the app.
The commercialisation checklist
Run this before you charge anyone money, or before you let the business depend on it. If you cannot tick an item, that is your next job.
Ownership
- The app has a business owner: someone who understands how the product should work, holds the vision, and is ultimately accountable for the system. This matters most for internal builds, where it is easiest to skip.
- The app has someone, or a process, for quick updates, so it does not go stale and musty over time.
Surface
- The feature list is cut to the smallest thing that works end to end.
- Payments go through Stripe. Raw card data never touches your servers.
- Logins and identity are handled by a dedicated provider, not homemade.
Architecture
- The architecture was designed once you knew what the product was, not accumulated while you found out.
- Every important action is enforced at the API and data layer, safe even if called directly.
- Multi-tenant data is isolated with row-level rules from the first commit.
Hygiene
- Every secret is out of the code and out of version history.
- Any key that has ever been committed has been rotated.
- Every dependency is verified as real, maintained, and version-pinned.
Process
- Automated and AI-driven security testing runs continuously, not just once.
- The AI builds from your codified skills and workflows, not generic out-of-the-box defaults.
- A pipeline checks every change before it reaches users.
- Changes ship small and deliberate, not in big sweeping edits.
- Human review is reserved for the architecture and the money-and-data paths.
Tick all of those and you have taken most of the risk off the table while keeping the speed that got you here in the first place. You no longer have a vibe coded app. You have an AI-Managed App.
Where this gets hard, and where we come in
None of this is beyond a capable technical founder. But most people who vibe code something valuable are not security engineers, and the whole point was to not need one. That is the trap: the app works, the vulnerability is invisible to you, and you find out the expensive way.
This is exactly the handover BusyWork Dispatch is built for. You explore and shape the idea with your AI, then send the request straight from ChatGPT, Claude or Cursor. Our team picks it up, scopes it against a capped budget you approve first, builds it properly on audited services and sound architecture, tests it, and hands it back ready to use. Security reviews and ongoing maintenance are part of the model, not a one-off audit you have to remember to book.
You get to keep moving at AI speed. We make sure that what ships is actually safe to sell.
A vibe coded app is not unsafe because AI wrote it. It is unsafe when nobody is looking after it. The answer was never to hand it back to humans and slow down. Shrink the surface, lean on audited services, teach the AI your workflows, and let AI guard it continuously while a human owns the outcome. That is an AI-Managed App, and it can be as secure as anything else on the market.
If you have vibe coded something people want, and you want it hardened into a real product without hiring a dev team or a security firm, book a call with Ben or read how the model works.
