Somebody in your network probably did this in the last month. They cancelled the big per-seat CRM contract, spent a weekend prompting an AI tool, and walked out with a custom app that does exactly what their business needs and nothing it doesn't. Their software bill dropped somewhere between 40 and 80 percent.
They are not lying to you. The savings are real. I want to say that clearly before I say anything else, because the lazy take here is to roll my eyes and tell you the software vendors were right all along.
They weren't.
If you were paying six figures a year for a CRM and using maybe a tenth of it, you were paying a tax on features built for a company ten times your size. A recent trade roundup covered five small companies, 20 to 70 people each, that dropped their big CRM contracts over six months and rebuilt with AI tools. One survey found roughly 59 percent of admins say their CRM has gotten too complex to work with. That's not a marketing problem. That's a real one, and you felt it every time you logged in.
The wins are easy to find. A 55-person firm went from around $100,000 a year to about $3,600. A pro rugby club replaced two separate platforms in four months and cut roughly $100,000 in spend. These are sympathetic, sensible people who looked at their invoice and did the obvious thing.
So this isn't a "don't do it" post. It's a "know what you actually built" post.
Cheap to build and safe to depend on are two different questions
Here's where the reporting stops and the part that matters starts.
A social app launched earlier this year. The founder was proud that he didn't write a single line of code. Within three days, researchers found the entire production database sitting wide open. About 1.5 million API tokens, 35,000 email addresses, and a pile of private messages, all readable by anyone who looked.
The root cause wasn't some genius exploit. The admin key to the database got shipped inside the JavaScript that runs in every visitor's browser, and the row-level security that would have blocked public reads was never switched on. One setting. Off by default.
It looks like this, roughly:
// this line runs in every visitor's browser
const db = connect(DATABASE_URL, ADMIN_KEY); // full read/write, no login required
A competent engineer sees that and flinches. The admin key never leaves the server. The public gets a scoped, authenticated path and nothing else. That reflex is the whole job, and a prompt doesn't have it.
Same story with an ID-verification app that asked users for a selfie and a government ID at signup, then stored them in a bucket set to allow anonymous reads. Around 70,000 images got pulled and posted publicly, including roughly 13,000 driver's licenses and passports.
These aren't edge cases. They're a checkbox a senior engineer flips without thinking, and a model doesn't flip because you didn't know to ask.
The numbers back up the pattern
AI-generated code carries more security flaws than human-written code, and it isn't close. In one analysis, when models were forced to choose between a secure method and an insecure one, they picked the insecure one about 45 percent of the time.
It gets worse the more you prompt. Researchers found that after five rounds of "just make it work," the code had 37 percent more critical vulnerabilities than the first version. That's the exact loop of vibe coding. You keep asking until the demo runs, and every round you're quietly stacking risk you can't see.
None of this means the tool is bad. It means the tool writes code the way a very fast junior would, and nobody senior is reading it.
You didn't buy ownership. You rented one person's memory of a conversation.
The reporting frames the new lock-in as custom workflows you keep piling on. That's not the real trap.
The real lock-in is the person who ran the prompt.
There's no repository anyone else can read. No docs. No one who can patch a vulnerability when it drops, rotate a key after it leaks, or keep the thing running when that person takes a two-week vacation or leaves. Your system of record, the place your customer data actually lives, exists because one human remembers roughly what they typed into a model at 11pm on a Tuesday.
That's not ownership. That's a single point of failure with a login, and it also happens to be the only person who can sign off on its own work. Same AI writes the code, same AI reviews it. The appearance of a second set of eyes with none of the safety.
Even the CRM vendors are saying the quiet part. Their line is that you can't vibe-code your way to enterprise reliability. They're half right. The honest version is this: you don't need their reliability, and you don't need their $100,000 contract. You need someone who owns reliability. That can be a partner instead of a seat meter.
Where the line actually goes
There's a sane way to think about this, and it's not "go back to the expensive thing."
Vibe-code freely for the low-stakes stuff. Prototypes. Internal dashboards nobody outside the building sees. A tool that formats a report. If it breaks, you shrug and re-prompt.
The moment an app touches logins, payments, customer PII, or health data, someone has to own it. Not babysit it. Own it. Read the code, lock down the data, know where the keys are, and be able to hand the whole thing to the next person without a séance.
That's the gap between the app that worked in the demo and a system of record you can actually depend on. Closing that gap is the entire job. It's what we do. We take the thing you built cheap, keep the savings, and make it safe to run your business on, or we build the version that was safe from the first commit.
Keep the money you saved. It's real, and it's yours. Just make sure the thing holding your customers' data has more than one person's memory standing between it and the front page.
We handle this for small businesses every day, and the first conversation is free with no commitment. Subscribe free at kief.studio for the companion checklist on what's safe to vibe-code and what needs an owner.