So You Vibe Coded Your Own CRM. Now Who Patches It?

Let me start with the good news, because there genuinely is some.

Anyone with a Claude Code subscription and a decent idea can now build software that would have cost sixty grand and taken four months two years ago. Small businesses that have been bleeding money on CRM and ERP subscriptions for decades can suddenly build the exact tool they need, with the exact fields they want, without paying a per seat licence to a vendor in San Francisco who ignores their feature requests. That is a legitimately brilliant shift and I'm not going to pretend otherwise. I'm a GET SHIT DONE person. This gets shit done.

Now the part that bothers me the most.

Almost nobody deploying these things has answered the boring questions. Not the fun questions like "can the AI build it", because the answer is obviously yes. The boring ones. Who patches it? Who owns the repo? Has a human being actually read the code? What happens when the person who built it walks out the door with the entire thing living in their personal ChatGPT history?

First, the code itself is worse than you think

Before we even get to operations, let's deal with the output.

Researchers at OX Security found 62% of AI built applications ship with critical security vulnerabilities. Carnegie Mellon found that while 61% of AI written code functions correctly, only 10.5% would pass a proper security review. Georgetown's CSET tested AI code against cross site scripting, an attack older than most of the people using these tools, and 86% of it failed.

Escape.tech scanned over 5,600 vibe coded applications running in the wild. They found more than 2,000 exploitable vulnerabilities, over 400 exposed API keys and credentials sitting in plain sight, and 175 cases of exposed personal data. A separate Tenzai study in December 2025 took 15 apps across five platforms. Every single one had a server side request forgery flaw. Zero had CSRF protection. Zero had basic security headers turned on.

So that's the starting position. The code arrives with holes in it. Everything below is about what happens after you deploy those holes.

Day two: the questions nobody asked

The build is the easy 10%. The other 90% is running the thing for the next five years. This is where SaaS platforms were quietly earning their subscription fee and you never noticed.

Who patches it? Your app has dependencies. Dozens of them, probably hundreds once you count what those depend on. Those packages get vulnerabilities disclosed constantly. Somebody needs to be watching for that, testing the update, and deploying it. Is that person you? Do you have a process, or does patching happen when something breaks? And it's not only the libraries. The runtime goes end of life. The operating system needs patching. The container base image gets a critical CVE at 11pm on a Friday. Your SaaS vendor was doing all of that silently. Now it's yours.

Has it been penetration tested? Not "did the AI say it looks secure". An actual test by someone whose job is breaking things. If the answer is no, you don't know what state it's in. You're guessing, and the stats above suggest you're guessing wrong.

Did a human read the code? This is the big one. If nobody with real skill has read what went to production line by line, then the security posture of your business is currently set by a model that was optimising for "does this run", not "is this safe". Reading it after the fact is also harder than people expect, because AI generated code is verbose, inconsistent between sessions, and often solves the same problem three different ways in three different files.

Where's the source code? In a proper Git repository with history and branches, or in a folder on someone's laptop called "final_v3_actual_final"? Who else has access? If that laptop dies tonight, does your business still have its software?

Is there a staging environment? Or are changes going straight to the live system that your staff and customers are using? If the answer is the second one, you're one bad prompt away from a very bad Tuesday.

The security controls that SaaS gave you for free

Every enterprise platform you were paying for came with a pile of stuff bundled in. Vibe coded replacements almost never have any of it unless someone deliberately built it.

• Single sign on and MFA. Most vibe coded apps ship with a homemade username and password login. That's a step backwards from 2015. Can you enforce MFA? Can you tie it to your Entra ID so that offboarding someone actually removes their access?
• Role based access control. Can a junior see the entire customer database? In most of these apps, yes, because permissions were an afterthought and everyone got admin so the thing would work.
• Audit logging. If something goes missing or gets changed, can you prove who did it and when? Without logs you cannot investigate an incident. You just have a bad feeling and no evidence.
• DDoS protection and rate limiting. If it's public facing and there's no WAF or rate limiting in front of it, one bored person with a script can take you offline or brute force your login page all afternoon.
• Secrets management. Those 400 exposed API keys Escape.tech found didn't get there by accident. They got hardcoded straight into the source because that's the path of least resistance and the AI didn't argue.
• Encryption and backups. Is the database encrypted at rest? Are there backups? And the question everyone gets wrong: has anyone ever actually restored from one to prove it works? An untested backup is a rumour.
• Monitoring and alerting. Who gets woken up when it falls over at 3am? What's the escalation path? SaaS had a status page and a support line. You have a mate who's asleep.

The paperwork nobody made

Governance sounds like the most boring word in business and I understand why people's eyes glaze over. But it exists because of exactly this situation.

There are no design documents. No as builts. No data flow diagram showing where customer information actually travels. No architecture decision record explaining why the thing works the way it does. No change management, so nobody approves anything, it just appears. No test suite, so nobody knows if today's change broke last month's feature. No version control discipline, so there's no rolling back.

Then there's ownership. If a contractor built it on their personal AI subscription, read that subscription's terms and read your contract with them. Who owns the output? Is there an IP assignment clause? And separately, AI models have been known to reproduce chunks of training data, which means open source licensed code can end up in your commercial product without anyone knowing. That's a legal problem that surfaces years later, usually during due diligence when someone's trying to buy your company.

The worst one: when the vibe coder leaves

Your vibe coder leaves. What actually walks out the door with them?

Not just the code. The reasoning. Every prompt, every clarification, every "no do it this way instead" that shaped the system is sitting in a chat history on their personal account. The code is the output. The conversation was the design document, and you never had a copy of it.

With a trained developer you have a fighting chance. Their code is idiomatic, other developers can read it, and they've usually been beaten into habits like commenting, documentation, and structured commits by years of working on teams where doing otherwise gets you yelled at. They've simply been taught to leave things in a state where the next person can pick it up.

A vibe coder often hasn't. And because the code is machine generated in inconsistent styles across hundreds of sessions, the next person can't reverse engineer the intent easily. They frequently conclude the fastest path is to bin it and start again, which means you paid for the same system twice.

I want to be fair here. Hiring a trained developer with no process and no oversight produces a mess too. Plenty of terrible software has been written by qualified people. The difference is that a trained developer usually knows the questions exist. A vibe coder often doesn't know what they don't know, which is a completely different flavour of risk.

The bills that arrive later

A few things that come back to bite well after go live:

Cyber insurance. Read your policy. Some require reasonable security measures or specific controls to be in place. Discovering during a claim that your core business system was never reviewed, tested, or patched is a rough way to find out where you stand.

Enterprise customers. The moment you try to sell to a decent sized company, you'll get a security questionnaire. They'll ask about your SDLC, your patching cadence, your pen test results, your access reviews. "We vibe coded it and it's been fine so far" is not an answer that wins contracts.

Legal exposure. If you're holding customer data and it leaks, that's your problem to explain, and the explanation matters.

Exit strategy. You dumped the CRM subscription. Fantastic. Now if the vibe coded replacement falls over, how do you get your data out of it and into something else? A commercial platform has export tooling because they legally have to. Your custom app has whatever someone thought to build, which is usually nothing.

Shadow IT. Half the time nobody in IT even knows these apps exist until something breaks. You can't secure an asset you don't know you own.

How to actually do this without killing the speed

I'm not telling you to go back to paying for software you hate. Use the tools. Just put a floor under it. Before anything vibe coded touches real customer data or the open internet:

1. A human who can actually read code reviews it. Not the AI reviewing itself. A person.
2. It sits in version control you control, in your organisation's repo, not on a laptop.
3. Secrets live in a secrets manager. Zero credentials in the source code, ever.
4. Authentication goes through your existing identity provider with MFA enforced.
5. Permissions are defined by role, and someone reviews who has access every quarter.
6. There's a staging environment and changes get tested there first.
7. Backups exist, are encrypted, and someone has performed a test restore.
8. If it's public facing, put a WAF and rate limiting in front of it. This is cheap.
9. Logging is turned on and going somewhere you can actually search.
10. Someone writes down how it works. One page minimum. What it does, what it connects to, where the data lives, who to call.
11. Dependencies get scanned and patched on a schedule, not when something explodes.
12. Before it goes live with anything that matters, get it pen tested.
13. Contracts with whoever built it assign the IP to you and require handover of documentation.

That's not red tape. Half of it is an afternoon's work and most of it is a one time setup. Compare that to the cost of your customer database turning up on a forum.

Vibe coding is a genuine leap forward and I'd rather businesses build their own tools than get held hostage by subscription pricing. But building software was never the hard part of owning software. Running it safely for years, with people coming and going, is the hard part. AI made the first bit almost free. It didn't touch the second bit at all.

Build the thing. Just don't pretend the job's finished when it runs.