I was at an AI event a few weeks ago when someone casually mentioned they'd vibe-coded their own CRM. Prompted into existence in a day to support their use-case. It sounded impressive in the moment. But it got me thinking about a question that keeps showing up on X, on LinkedIn, in Slack channels: ~how much building is actually enough?~
The build-versus-buy debate isn't new. People have been arguing about it (if youβre on X, Reddit, or LinkedIn, it feels like weβve been arguing for ages). And it has been in different forms, wrappers, itβs just Excel, but with a better UI, and other flavors.
What changed is that AI made the "build" side feel almost free. You can prompt your way to a working prototype in a few hours. The problem is that prototypes and production systems are very different things, and the gap between them is where teams quietly lose months.
The weekend project that becomes a full-time job
It usually starts the same way. A product manager or an engineer gets frustrated with the tools the company is paying for. HubSpot is too bloated. Salesforce is too expensive. The internal admin panel is held together with duct tape. So they spend a weekend vibe-coding a replacement. It works. People start using it.
Then the feature requests come in.
The sales team wants approval workflows. Marketing wants a reporting dashboard. Someone needs an email integration. Each request feels small. A day here, two days there. But they compound. An engineer at incident.io described exactly this pattern after building an internal expenses platform as a side project. The finance team wanted to tweak reporting. Then an approvals step. Then the manager tracks. Then bugs started surfacing.
The tool that was supposed to save time became the thing eating all of it.
Nobody posts about the six months of maintenance that follow the weekend build. That part doesn't make it into the X thread.
Your job was not to maintain a CRM
The person who vibe-coded the CRM is usually a product manager, a developer, or an ops lead. Their actual job is to build the product, ship features, or run operations. Maintaining an internal CRM was never part of the role. But now it is, because they built it and nobody else understands how it works.
The Retool team calls this becoming an "unexpected product owner." You built a tool to solve a problem. Now you need a roadmap for it. You're fielding bug reports from colleagues. You're the on-call support person for software that was supposed to be a shortcut.
The strain scales with the team. Say you started with 3 salespeople using your vibe-coded CRM. Now there are 10 salespeople and 20 engineers also relying on it. The engineers can fix their own issues, sure. But the salespeople can't. They file requests. Those requests stack up. Your actual work stalls.
The security problem that shows up later
When you vibe-code something for yourself, security is an afterthought. You're moving fast, testing ideas, seeing what works. But the moment other people start using it with real customer data, you've taken on a serious liability.
A study cited by Evil Martians found that vibe-coded output is "especially prone to critical security flaws." The UK's National Cyber Security Centre issued a warning in 2025 that vibe coding poses a major risk to businesses. Forbes ran a piece in March 2026 titled "Vibe Coding Has A Massive Security Problem." These aren't outlier opinions.
The issues themselves are basic but damaging. API keys hardcoded in the codebase because pasting them into a config file was faster during prototyping. No real authentication layer because auth is tedious to implement and the tool only had 3 users at first. Unaudited dependencies pulled in by AI-generated code, creating supply chain risks nobody consciously accepted. XSS and injection vulnerabilities that established products have entire teams patching, but your weekend CRM does not.
Each of these is fixable if you dedicate an engineer to the tool. But that's the whole point. You now need a dedicated engineer for the thing you built, rather than buying a product that already handles all of this.
The cost math that people skip
A HubSpot seat costs roughly $50 to $100 per month for the Starter plan. For 10 salespeople, that's $500 to $1,000 per month. Call it $12,000 a year on the high end.
An engineer's fully loaded cost in a mid-tier market is somewhere between $120,000 and $180,000 per year. If that engineer spends even 25% of their time maintaining the vibe-coded CRM, you're paying $30,000 to $45,000 a year for something HubSpot would have covered for $12,000. And you're losing a quarter of that engineer's output on your actual product.
The ratio only tilts further as the tool grows. More users mean more bugs, more feature requests, and more security patches. Industry data from Vention puts software maintenance costs at 15 to 20 percent of the original development cost per year. For an internal tool that keeps accumulating features, that percentage climbs.
When vibe-coding actually makes sense
The answer isn't "never build." Some things should be built. The question is which ones.
If you only use it occasionally, vibe-coding is fine. A script that reformats your CSV exports. A personal dashboard that pulls data from three APIs. A quick tool that automates a task you do twice a month. Low-frequency, single-user, no security surface worth worrying about.
If the tool is core to what makes your product different, building makes sense. Your product's main workflow should not depend on a third-party tool that could change its API, raise prices, or shut down. Build the things that set you apart.
If you're exploring whether an idea has legs, a vibe-coded prototype is a great way to test it. Build it in a day, show it to the team, see if people actually use it. But treat it as a prototype. If it sticks, either invest in building it properly or buy something that does the job.
When you should just buy
If the tool is not your core business, and someone else already built a good version of it, buy it. CRM, project management, email marketing, analytics, support ticketing. Companies selling these tools have security teams, compliance certifications, uptime SLAs, and hundreds of engineers maintaining them. You cannot replicate that with a weekend build, and you shouldn't try.
If multiple teams need the tool, buy it. Cross-team tools need consistent behavior, permissions, integrations, and support. A vibe-coded tool built by a single person will reflect that person's understanding of the problem. The sales team's needs differ from marketingβs, which differ from engineering's. A product company has spent years reconciling those differences. You haven't.
If the tool touches customer data, buy it or build it with a proper engineering process. Not a vibe-coded prototype that got promoted to production because nobody had time to replace it.
The real question
The build-versus-buy debate keeps getting framed as a technical decision. It's not. It's about where you want your team spending their time. Itβs a time-bound question, and the answer is pretty clear: Do you have time?
Every hour an engineer spends patching a vibe-coded internal tool is an hour not spent on your product. Every bug report from the sales team about the homegrown CRM is a distraction from work that actually moves the business forward.
The weekend build feels free because the only visible cost is the weekend. Maintenance, security exposure, support load, lost engineering capacity: those costs stay hidden until the tool is load-bearing and migrating off it is its own project.
That person at the AI event who vibe-coded their CRM is probably either still maintaining it and wishing they weren't, or they've already moved to a paid product and eaten the migration cost. Both outcomes could have been avoided by asking one question at the start: Is this something my team should own, or has someone else already solved it?
References:
- Evil Martians - "The 4 most common security risks when vibe coding your app."
- NCSC (UK National Cyber Security Center) - Warning that vibe coding poses a major risk to businesses (2025)
- Forbes - "Vibe Coding Has A Massive Security Problem" (March 2026)
- CMU (Carnegie Mellon University) - Paper benchmarking security of AI-generated codebases
- Retool - "Build vs buy: a guide for internal tools" (the "unexpected product owner" concept, incident.io expenses anecdote)
- Vention - Software maintenance costs benchmark (the 15-20% annual maintenance figure)
- Kaspersky - "Security risks of vibe coding and LLM assistants for developers."
The incident.io anecdote was taken from a link in the Retool article pointing to incident.io - "Build vs Buy". The HubSpot pricing figures are from their public pricing page.
Top comments (0)