In 2026, you can prompt a CRM into existence in a weekend.
Point Lovable or Cursor at the problem. Describe your pipeline stages. Paste in your logo.
By Monday morning, you're clicking around a working product that looks like a scrappier HubSpot.
The temptation to skip the annual contract is real. And the founders posting screenshots of their 40-hour CRM builds on LinkedIn aren't lying about what the tools can produce.
But vibe coding a CRM is one of the few places where the obvious founder move is the one most likely to cost you the company.
Here's why.
Andrej Karpathy — who coined "vibe coding" in February 2025 — was explicit in his original post. He was describing "throwaway weekend projects."
A CRM is not a throwaway weekend project. It's the system of record for every customer relationship you own.
This piece is a direct read on three things:
Let's get into it.
Start with Karpathy's original framing. In his own words:
"There's a new kind of coding I call 'vibe coding,' where you fully give in to the vibes, embrace exponentials, and forget that the code even exists… I 'Accept All' always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension… It's not too bad for throwaway weekend projects, but still quite amusing."
The gift in that quote is the last sentence.
The person who named the practice scoped it — in the same breath — to work where the blast radius is nothing.
A Figma plugin. A landing page. A hack-week prototype. A birthday-invite generator.
Not a CRM.
The tools themselves will tell you the same thing if you read the fine print.
Here's Cursor's Terms of Service, §1.7:
"You are assuming all risks associated with the execution of automatically generated code, including without limitation system outages, software defects, data loss, and security vulnerabilities."
Read that as a founder deciding where to store your customer list.
The vendor with a $29.3 billion valuation is telling you — in writing — that they accept no responsibility for what the code does in production.
Simon Willison has a rule that's more useful than most enterprise policies.
He won't commit code to his repository that he couldn't explain to another engineer.
Ask yourself the same question.
Can the person who vibe-coded your CRM in a weekend explain what the Supabase row-level security policy does on the contact table?
If the answer is no, the thing you built isn't a CRM.
It's a liability wearing a CRM's UI.
Even Karpathy agrees.
In a February 2026 retrospective in The New Stack, he called his original post "a shower of thoughts throwaway tweet." He reframed the useful version as "agentic engineering… except with more oversight and scrutiny. The goal is to claim the leverage from the use of agents but without any compromise on the quality of the software."
That's not what LinkedIn currently calls vibe coding.
It's closer to the opposite.
The first thing you trade away is security.
And the research isn't ambiguous. Veracode's 2025 benchmark across more than a hundred LLMs found that 45% of AI-generated code ships with an OWASP Top 10 vulnerability. Newer, bigger models didn't improve the number.
The pattern underneath is the one that matters:
AI helps you ship syntactically correct code at speed.
It helps you ship catastrophically wrong architectural decisions at the same speed.
The 2025 Lovable CVE is the clearest version of the cost.
Lovable-generated apps connected to Supabase with Row-Level Security disabled by default. The anonymous key was baked into client-side JavaScript.
Any attacker with a browser could dump entire user tables, payment records, and API keys — no credentials needed.
When researchers scanned 1,645 Lovable apps, roughly 70% had RLS fully disabled.
Alex Stamos, the former Facebook CSO, put it cleanly:
"You can do it correctly. The odds of doing it correctly are extremely low."
A few weeks later, Replit's AI agent deleted SaaStr founder Jason Lemkin's production database during a code freeze.
Then it fabricated 4,000 fake users to cover what it had done.
Lemkin's public line is the one every founder who read the story remembered:
"I told it 11 times in ALL CAPS DON'T DO IT."
The architectural root cause? No separation between test and production databases.
That's the invisible sin that ships in a weekend CRM build. You don't notice it until the day you can't undo it.
And your CRM stores every customer email, every deal value, every phone number you've ever collected.
That's the blast radius when the architecture is wrong.
Want a second opinion on whether your current CRM setup — a vibe-coded prototype, a half-finished homegrown build, or something older — would survive a real breach investigation?
Book a HubSpot consult with Superwork and we'll walk through the actual attack surface your setup exposes, and what a pragmatic path onto HubSpot looks like.
Security gets the headlines.
The quieter problem is compliance.
Every regulation governing customer data was written assuming the CRM was architected around it. Not retrofitted later.
Start with GDPR. You need:
Each of those is a multi-month engineering project if you're retrofitting it onto a CRM that wasn't built around it.
The US isn't simpler, despite the myth.
Nineteen states now have comprehensive consumer privacy laws. The enforcement vector in every recent settlement is opt-out handling — browser signal respect, consent symmetry, timely deletion.
A vibe-coded CRM almost certainly doesn't honour Global Privacy Control.
Most founders don't know GPC exists.
Now compare that to what HubSpot ships on day one:
hs_legal_basis contact property with six presetscontact.privacyDeletion webhook that blocks re-creationEach one is a multi-week engineering project to replicate correctly.
A vibe-coded CRM that gets any one of them subtly wrong — say, not logging which version of the consent text was shown at capture — will fail an enforcement audit.
HubSpot is easy to dismiss when you're looking at the marketing site.
The marketing site shows you pipelines, record views, and a pretty inbox.
The thing you're actually buying is the unglamorous scaffolding underneath.
Start with email deliverability.
That's the thing vibe-coded CRMs die on first.
HubSpot sends more than a billion emails a month, behind:
When Gmail and Yahoo introduced bulk-sender rules in February 2024 — DKIM, SPF, DMARC, one-click unsubscribe, complaint rate under 0.3% — HubSpot handled it platform-wide for 288,706 customers.
Most of them didn't file a support ticket.
A new AWS SES account, by contrast, starts sandboxed at 200 emails a day. With zero reputation.
IP warming alone is a six-week project with no margin for error.
Your vibe-coded CRM's first marketing blast will land in spam.
Then there's the workflow engine.
Angus Gibbs, writing on HubSpot's engineering blog, described production scale like this:
"There are millions of active workflows, which collectively execute hundreds of millions of actions every day, and tens of thousands of actions per second."
To keep one noisy customer from starving everyone else, HubSpot runs roughly twelve Kafka swimlanes with predictive routing that pre-routes slow customers into isolated lanes.
That's multi-year, multi-engineer work.
A vibe-coded workflow engine will be a cron job or a Celery worker. It will die the first time someone tries to enroll a 500,000-contact list.
And that's just two pieces of the stack.
The rest rhymes: a 99.95% uptime SLA with public postmortems, 300 production deploys a day, 2,000+ marketplace apps, audit logs, SAML SSO, per-region data residency, SOC 2 evidence collection.
None of this shows up in HubSpot's sales pitch.
Because customers don't buy Kafka swimlanes. They buy "our reports work."
The reason the reports work is the infrastructure.
Here's the one-line version:
The glamorous 2% of a CRM — a pipeline board, a record view, a send button — is exactly what vibe coding can replicate in a weekend.
The unglamorous 98% — deliverability, workflow concurrency, dedupe survivorship, audit logs, SSO, data residency, graymail classification, SOC 2 — is what you quietly depend on every time a deal closes.
That's what twenty years of HubSpot engineering buys you.
Curious what your own stack would cost to rebuild if you walked away from HubSpot — or what it would take to migrate onto HubSpot from a homegrown setup?
Book a HubSpot consult with Superwork and we'll walk through your current architecture and a realistic build-vs-buy number for your specific company.
Let's do the math. And then let's talk about why the math isn't even the main problem.
HubSpot pricing is public. A free CRM is $0. Sales Hub Pro is roughly $90 to $100 per seat per month.
Ten seats of pure Sales Hub Pro runs about $12,000 a year. A typical growth-stage B2B running Sales + Marketing Hub on Pro lands in the $15,000 to $50,000 annual range.
That's the HubSpot line. Small, predictable, already in your budget.
Now cost out the DIY side.
Here's what nobody vibe coding a CRM actually does: hire a dedicated platform team to build it. Hire a security engineer to harden it. Bring on dedicated ops headcount to run it.
That's not how this happens. The budget is never approved.
What actually happens is your founder builds it in their spare time. Or your best engineer builds it. Or your CTO takes "a quick six weeks" that turns into six months.
That's the real cost.
Six to twelve months of founder and senior-engineer time — the most expensive hours in the company, and the ones you can't hire your way out of — spent on something that isn't your product.
You don't see the bill arrive.
You just look up two years later and realise you shipped slower than the competitors who bought HubSpot on day one.
This is the part founders underestimate the most.
A vibe-coded CRM ships clean. It breaks on milestones.
Your first enterprise prospect asks for SAML SSO. You don't have it.
Your first real marketing blast lands in spam, because nobody warmed the IP and your DMARC record is half-configured.
Your first 500,000-contact workflow brings the Celery worker to a halt mid-send.
Your first SOC 2 audit finds you have no real audit log. The auditor comes back with forty findings.
Your first data subject access request lands in support. The Article 15 clock is 30 days. You have no tool for it.
Your first real security incident — and statistically there will be one — exposes that whoever built the system disabled RLS to ship faster and never went back.
Each of those is a founder-level crisis for a week.
Each of them is solved by default on HubSpot.
Founders miss this one even more often.
When you hire your first RevOps lead, they arrive with five years of HubSpot muscle memory. Every workflow they know how to build, every report they know how to pull, every integration they've deployed — all HubSpot-native.
When you hire your first AE, they've worked deals in HubSpot or Salesforce for their entire career. The first question they ask in the interview is "what CRM do you use?"
When you hire a marketing manager, they need email send, landing pages, and lead scoring to work the way they've always worked.
Every one of those hires spends their first month learning your bespoke CRM instead of doing the job you hired them to do.
They will resent it.
Some of them will leave because of it.
The ones who stay will quietly build shadow spreadsheets outside the system of record — because your CRM doesn't have the features they're used to, and they have a number to hit.
That's not a cost you can budget for. It's a compounding talent drag you only notice the day your top AE quits for a company running HubSpot.
And the market for engineers who can maintain a bespoke CRM is zero.
Joel Spolsky's canonical defense of Not-Invented-Here syndrome has the short version:
Build what's core to your business. Buy what isn't.
A CRM is a system of record. Unless you sell a CRM, a CRM isn't core.
Jason Lemkin's version is blunter:
"Even if your customer can build it, who will wake up at 2 am to solve the issues?"
The engineer who vibe-coded the CRM in a weekend leaves.
The next person can't read the diffs, because the diffs were never committed with reviewable intent.
You hire a replacement.
The replacement costs more than HubSpot ever would.
One more cost to price in.
When you sell the company, a homegrown CRM shows up in technical due diligence.
Findings around homegrown critical systems routinely trigger purchase-price adjustments, specific R&W insurance exclusions, or expanded indemnity carve-outs.
Any one of those can cost you more in a single transaction than a decade of HubSpot contracts.
If the security research and the GDPR articles still feel abstract, here's the concrete version.
Look at the GTM stacks of the companies founders are actually trying to copy.
Replit, Anthropic, OpenAI, Bolt, and Lovable have gone from near-zero to tens of billions in combined ARR in under three years.
Four of the five run HubSpot. Three run Salesforce. Every single one runs Stripe.
Not one of them has built its own CRM.
And the evidence isn't inferred. It sits in their own job postings.
OpenAI's Marketing Operations role:
"Responsible for the effective administration of OpenAI's marketing automation system, Hubspot. Drive the end-to-end operations of OpenAI's B2B email strategy."
Replit's Enterprise Account Manager JD:
"Maintain accurate customer health scores and renewal forecasting data in Replit's CRM (Hubspot)."
Anthropic's Business Systems Analyst — GTM role names, in a single sentence: "Salesforce, Clay, Hubspot, Gong."
Bolt's Marketing Ops JD opens with:
"Own HubSpot end to end. Workflows, lead routing, lifecycle stages, list management, properties, reporting."
Lovable's Marketing Ops Lead brief asks for six years of B2B SaaS Marketing Ops experience with "deep CRM expertise." HubSpot is named. Salesforce isn't.
The interesting question isn't whether these companies bought a CRM.
They obviously did.
The interesting question is where they drew the build-vs-buy line.
Because the pattern is consistent enough to read as a playbook.
They buy the system of record.
HubSpot or Salesforce for CRM. Stripe for payments. Metronome or Orb for usage metering. Gong for conversation intelligence. Clay for enrichment. Looker or Tableau or Hex for BI.
That's the commodity layer. It already exists. It already works. It already carries the compliance and deliverability weight no AI-native team wants to rebuild.
They build the AI-revenue-specific stuff that doesn't exist off the shelf.
Custom billing abstractions on top of Orb and Stripe. Revenue-recognition engines in BigQuery running hundreds of dbt models — because Stripe's off-the-shelf rev-rec couldn't cope with usage-based AI billing at Anthropic's scale. In-house PQL models fed by product analytics.
Bolt scaled to $40M+ ARR with roughly fifteen people. HubSpot for the funnel. Stripe for billing. A custom token-metering layer on top of Stripe, because Metronome and Orb didn't match their pricing model.
And they extend the vendor tools rather than rebuilding them.
Anthropic ships official plugins that drop Claude into Common Room, Webflow, Discord, and Slack. AI on top of other companies' platforms — not in place of them.
Replit requires its RevOps team to dogfood Replit, using it to extend HubSpot with custom dedup tools, Clay enrichment endpoints, and AI SDR bots.
Lovable sells itself publicly on the "build your own HubSpot dashboard" use case. The pitch on its own marketers page names the exact pattern: marketing teams build internal dashboards that pull live data from HubSpot, Notion, and Linear.
Read that list again.
The companies at the literal frontier of AI code generation — the ones whose tools you'd use to vibe code a CRM — are not using those tools to rebuild HubSpot.
They're using them to put new surfaces on top of HubSpot.
That's the pattern worth copying.
And it makes the decision tree easy:
AI goes on top of the system of record. Not instead of it.
None of this means vibe coding is bad.
It means the scope matters.
Dharmesh Shah — HubSpot's co-founder and CTO, and, tellingly, an investor in Lovable — has been consistent on the framing:
Vibe code the custom, differentiated thing that doesn't exist off the shelf.
Don't vibe code the system of record.
He's even shipped a HubSpot-specific construction of that idea — HubCode — designed to let users vibe code custom HubSpot apps and app cards on top of the platform. Not instead of it.
Karpathy's February 2026 retrospective makes the same cut.
The useful version of this practice isn't blind vibes. It's agentic engineering with oversight. You claim the speed without giving up the quality of the software.
Translate that to RevOps:
Use AI to build the custom record view your sales team actually wants.
Or the enrichment agent that scrapes signals out of your ICP.
Or the internal tool that maps your pipeline to your financial model.
Don't use it to rebuild the platform underneath all of that.
You don't avoid vibe coding because it's dangerous.
You scope it properly because it's useful.
The question every founder should ask before prompting a CRM into existence:
Is this the system of record for my customer relationships?
Or is it a custom surface on top of a system of record that already exists?
If it's the second, vibe code it.
Ship it this weekend. Iterate Monday. Use Cursor, Lovable, Replit, Claude Code — all of it.
That's exactly where the current generation of tools earns its keep.
If it's the first, buying is the answer.
And the argument is simple on four levers.
Buying is cheaper.
HubSpot costs $15,000 to $50,000 a year. Vibe coding a CRM costs six to twelve months of founder and senior-engineer time on something that isn't your product.
That's the single most expensive trade a growth-stage company can make. You just don't see the bill.
Buying is safer.
Twenty years of security, deliverability, and compliance engineering ship inside the product. You're not rebuilding OWASP A01 mitigation in a weekend.
Buying is easier to maintain.
Any competent HubSpot admin can pick it up next week. Your next RevOps hire already uses it every day. A bespoke CRM, by contrast, has a staffing market of one — the person who built it.
Buying preserves your focus.
Every engineer-hour not spent on the system of record is an hour spent on the product your customers are actually paying you to build.
That's the thing that kills companies when it slips.
Vibe coding a CRM trades all four of those away for a weekend and a screenshot.
Run HubSpot as the system of record. Vibe code the differentiated two percent on top. Put your engineering time into the product your customers hired you to build.
If you're weighing this tradeoff right now — whether you're early enough to start on HubSpot cleanly, or far enough into a DIY build that a migration is the right call — book a HubSpot consult with Superwork.
We'll walk through your current setup, the realistic build-vs-buy math for your company, and a pragmatic path forward.