I run a CRM. People keep asking if they should just vibe code their own.

It's not a niche question anymore. A Zapier employee literally DM'd me last week after their internal hackathon:

The DM that triggered this article. A Zapier employee tried to vibe code their own Breakcold during an internal hackathon with Cursor, gave up, and came back for the real thing. I wrote a full AMA about it on r/SaaS.

If a Zapier engineer with Cursor can't pull it off in a hackathon, that's a data point. But let's go deeper than that, because the honest answer is more nuanced than "no".

Dharmesh Shah just answered this. His framework is simple.

Dharmesh Shah, CTO and co-founder of HubSpot, posted his take a few days ago. He could have said "no, buy HubSpot." He didn't. He said this:

• Narrow use case, low maintenance: vibe code away.

• Wide use case, high maintenance: serious red flags.

• Wide use case, high maintenance, lots of users: don't do it.

A CRM is the third bucket. Wide use case. High maintenance. Lots of users over time.

This isn't a HubSpot marketing line. As the founder of an AI-native CRM, I think he's right. Biased, but not wrong.

The three objections, and where they collapse

1. "CRMs are expensive"

HubSpot starts free. Breakcold starts at $59 per month flat, plus $10 per seat. A 5-person team using a modern AI-native sales CRM is paying roughly $109 a month, all in.

Your time is not free. Two weekends of vibe coding a CRM costs more than a year of Breakcold. The math doesn't work, and it gets worse every month you spend maintaining the thing.

2. "I'll build exactly what I need"

True on day one. False by month three.

You will need to sync LinkedIn DMs. Then WhatsApp. Then your meeting recorder. Then your email. Then a calendar. Each integration is a project. Each one breaks when the upstream API changes. Each one needs auth refresh, retry logic, rate-limit handling.

A real LinkedIn CRM isn't a Postgres table with a "linkedin_url" column. It's a Chrome extension, a session refresh loop, a deduplication engine, a sync state machine. Same story for WhatsApp CRM integration. You can vibe code the first 5% in a weekend. The other 95% is what kills you.

Marco didn't build his own CRM. He looked at what HubSpot didn't do, found something that already did it, and moved on.

3. "We're AI-native, we know how to vibe code"

Cool. So does Lovable. So does Cursor. So does Replit. None of them built their own CRM.

They all use HubSpot or an AI-native HubSpot alternative. Because they figured out the same thing: the calories spent building a CRM are calories not spent on the product their customers actually pay for.

A homegrown CRM looks easy. Living with it for 5 years is the hard part.

This is the part vibe coders underestimate. Rachel Squire (CEO of MOBI Solutions, HubSpot and Marketo partner since 2012) wrote it perfectly. I'll quote her directly, because she's seen the full lifecycle dozens of times:

"I've lost count of how many times I've helped companies migrate off a homegrown CRM over the years. They all started with the best intentions: HubSpot, Salesforce, even something like Pipedrive or SugarCRM, seemed like a waste of money when you have a room full of developers sitting right there.

Fast forward 5 years. Now there's a full-time developer (or multiple) maintaining it. Every integration is custom built and takes 6 months to set up. Reporting requests run through the dev support queue. Integrating with Marketo may accidentally trigger an email to 'Hi Barbara (this person is an a**)' because the CRM wasn't built with the idea of integrating it with a customer-facing MAP one day. True story.

The next 100 people you hire all ask, 'why don't we just move to HubSpot or Salesforce?' and refuse to use your homegrown CRM, and eventually you can't take it anymore."

Rachel Squire, on LinkedIn

That's the part the hackathon demo never shows. Building V1 is fun. Living with the thing for half a decade is not. Setting up a CRM properly already takes effort. Building one from scratch and maintaining it is a different category of cost.

Even people leaving HubSpot after 13 years aren't building their own CRM. They're moving to a different CRM. That's the move.

Where vibe coding actually makes sense

Don't read this as "never vibe code anything." Vibe code aggressively where Dharmesh's first bucket applies:

• Internal dashboards that pull from your CRM.

• Custom reports your CRM doesn't ship out of the box.

• Slack bots that ping you when a deal stalls.

• Quick scripts that enrich a CSV before import.

• Anything narrow, low maintenance, low blast radius.

The smart move in 2026 is to vibe code on top of a real CRM, not vibe code the CRM itself. With MCP servers and a proper agent-friendly CRM, you get the database, the integrations, the auth, the channel sync, the inbox, the permissions, all done. You spend your AI calories on the workflows only you need.

So, should you vibe code your CRM?

If you're a solo developer with 30 contacts who wants a personal Rolodex: sure, vibe code it. Have fun.

If you're a sales team of 5 to 30, running real pipeline, talking to prospects on LinkedIn, WhatsApp, Telegram, email, and meetings: no. Buy the CRM. Spend that energy on the thing your customers actually pay you for.

Dharmesh said it best: every calorie spent vibe coding a CRM is a calorie not spent creating customer value. Your customers don't care what CRM you use. They care what you build for them.

I'm biased. So is Dharmesh. We're both right.

If you want the receipts: my full LinkedIn breakdown, the Zapier hackathon AMA on r/SaaS, and Rachel Squire's full post on what 12 years of homegrown CRMs look like.