Why “Vibecoding Your Own CRM” Almost Never Works

AI can build the first 80% of a CRM in hours. The remaining 20% is where most companies break their systems.

Vibecoding a Custom CRM vs Attio: the 80/20 reality

The current “vibecoding your CRM” wave (using tools like Claude Code or Lovable) is real, and the demos are legitimately impressive. In a few hours, you can produce an app that looks and feels like a CRM, often good enough to replace spreadsheets and reduce seat-based SaaS spend for small teams. That is not hypothetical: Lovable published a recent customer story about Atonom replacing a Salesforce contract with a Lovable-built CRM, claiming a major cost reduction, with the first version built in ~3 hours.

But the pattern the sources keep reinforcing is the same: the easy part is the “first 80%” (CRUD, views, dashboards). The hard part is the last 20% that makes a CRM operationally safe and durable: permissions, security, data integrity, auditability, edge cases, integrations, scale, and long-term maintainability. Even platforms with strong compliance posture explicitly frame security as a shared responsibility.

Attio’s core advantage is that it is already designed around that last 20% while still being unusually flexible: a configurable data model (objects, lists, attributes), enterprise-grade controls (permissions, SSO), and an AI-native layer (Ask Attio, Attio MCP) that is explicitly permission-aware and built around OAuth-scoped access.

After reviewing the most widely circulated “replaced Salesforce with a vibecoded CRM” claim, I can verify one concrete, named example (Atonom). I did not find a well-documented, independently audited example of a vibecoded CRM that is both widely scaled (large headcount, complex permissions, heavy integrations) and publicly evidenced as secure (clear threat model, app-level controls, testing) in the way enterprise buyers typically require.

What the evidence says about vibecoded CRMs right now

The most verifiable Salesforce replacement story circulating from the Lovable ecosystem is Atonom. Lovable’s customer story claims: Salesforce cost ~$40,000/year for ~25–30 users; a finance/legal leader built a working CRM prototype in ~3 hours; the company moved usage away from Salesforce; and the new system runs on Lovable at roughly ~$1,200/year including hosting.

There is also direct first-person corroboration from Atonom leadership on social, with some numerical inconsistency that’s worth calling out. Gabe Larsen describes “ripping out” a ~$30k Salesforce contract and building a CRM in ~3 hours on Lovable, costing ~$100/month. The direction matches the case study, but the exact numbers vary ($30k vs $40k; $1k vs $1,200).

Lovable also positions the broader “buy to build” narrative as viable at very large scale, citing eXp Realty (83,000+ agents) replacing or reducing multiple per-seat SaaS costs via internal software built with Lovable, including claims of eliminating ~$1M/year in per-seat licensing for an internal “Hub” product and saving ~$1M/year by replacing ChatGPT Enterprise custom chatbots with custom workflows using the OpenAI API. This is not a Salesforce CRM replacement story, but it is evidence that Lovable is used for mission-critical internal software in at least one large org.

On the “why the last 20% matters” question, the most useful sources are the ones that are unusually explicit about operational boundaries:

Claude Code’s own documentation emphasizes that agentic coding tools are powerful precisely because they can read code, modify files, and run commands, and therefore need a strict permission and approval model (read-only by default; explicit approval required for edits and shell commands; configuration of allow/ask/deny rules; warning against bypassing permissions outside isolated environments).

That caution is not abstract: recent reporting described a real incident where a developer’s production resources were deleted after delegating infrastructure changes to Claude Code with inadequate supervision and guardrails. The details are specific to that case, but the meta-lesson is transferable to “vibecoded CRM as a system of record”: agentic tools plus elevated permissions can create fast failure modes.

Lovable’s security posture is strong at the platform level (SOC 2 Type 2, ISO 27001:2022; enterprise security positioning; DPA language on maintaining certifications), but its docs also explicitly state that built-in security tools do not replace a thorough security review and that the builder remains responsible for app-level security decisions, especially for sensitive data or critical functions.

Attio’s engineering perspective is the closest thing to a “primary-source” articulation of why CRMs become hard at scale: it’s not just the data model, it is executing user-defined workflows reliably and at scale (Attio references thousands of workflows initiated every minute). This maps directly to the “last 20%” bucket: reliability, orchestration, and safe automation.

Draft Substack article in my voice

I keep getting the same question lately:

Should we just vibecode our own CRM with Claude Code or Lovable?

I understand the temptation. The demos are insane. You go from “I hate Salesforce” to a clean pipeline UI in a few hours. It feels like teleportation.

There’s a reason this trend is spreading. For a long time, “build vs buy” was a fake choice. Building internal business software was slow, expensive, and brittle. Now AI collapses the first part of the curve. A solid CRUD app is basically a prompt away.

But here’s my contrarian take:

Most teams are vibecoding the wrong thing.

They’re vibecoding the part that’s easy to demo, and underestimating the part that makes a CRM real.

The seduction of the demo

Let’s anchor this in a real example, not vibes.

Lovable published a customer story about Atonom, a startup that claims it replaced a ~$40,000/year Salesforce contract with a Lovable-built CRM for roughly ~$1,200/year including hosting, with the first prototype built in ~3 hours.

Atonom’s CRO (Gabe Larsen) posted publicly about ripping out a ~$30k Salesforce contract and building a CRM in ~3 hours on Lovable for ~$100/month. The exact numbers differ, but the narrative is consistent: rapid build, fast adoption, and a meaningful reduction in per-seat SaaS spend.

That’s the wow-effect.

And honestly, it’s legit. If your “CRM” today is a spreadsheet plus a weekly pipeline meeting, AI-assisted building can bring you to a working internal tool fast.

This is the part many people stop at. They look at the app, they look at the old CRM bill, and the conclusion seems obvious: we can just build it.

The 80/20 trap: the last 20% is the whole job

A CRM is not a UI. It’s an operational truth machine.

It becomes the system of record for revenue. It’s where you answer questions like: who can see which customer, which deals are real, what forecast is trusted, what happened, and who did what.

And that last 20% you don’t see in demos is where CRM complexity lives:

Security and permissions. The moment you have multiple teams, regions, contractors, or sensitive accounts, permissions stop being a checklist and become foundational product design. One misconfigured rule turns “internal tool” into “data leak.” The best agentic tools are explicit about this: Claude Code defaults to read-only, requires explicit approvals for actions, and warns against bypassing permission systems outside isolated environments. That is not paranoia. It’s product reality.

Data integrity and auditability. CRMs survive by being boringly correct. You need reliable workflows, consistent data modeling, history, and the ability to answer “what changed, when, and by whom.” That’s also why CRM platforms talk about running automation at scale and keeping it reliable. Attio’s engineering writing is unusually direct: once users can create workflows, the platform has to execute them reliably at scale, with thousands initiated every minute. That is the opposite of a demo.

Integrations. A CRM is never standalone. Email, calendar, enrichment, billing, product data, warehouse, support, outbound, attribution. The glue is the system. Claude Code can connect to external tools via MCP, but it also warns: third-party MCP servers are not all verified, and you should treat them as a trust boundary.

Maintainability. This is the silent killer. Even if you “own the code,” you also own the on-call. Lovable’s documentation is candid about the operational surface area you inherit if you stop using the platform for hosting and management: CI/CD, infrastructure, scaling, databases, backups, access controls, OAuth, secrets, monitoring, compliance posture. The cost doesn’t disappear. It moves.

And if you want a visceral example of how quickly it can go wrong, look at the recent incident reporting about a developer delegating infrastructure work to Claude Code and accidentally deleting production resources. Different context, same lesson: when AI has write access, guardrails are not optional.

So where do I land: build around the CRM, not instead of it

At Novlini, we’ve been testing these tools closely. My takeaway so far: vibecoding is amazing at producing focused tools and workflow-specific interfaces quickly. It’s less proven as a complete CRM replacement once you hit real-world complexity.

This is why I’m bullish on Attio as the baseline.

Attio’s core design is closer to “programmable CRM” than “legacy CRM.” The data model is flexible by default: you can define custom objects and lists, with a wide range of attribute types, and you start from the canonical primitives (people, companies, deals).

Then it adds something legacy CRMs are still awkward about: an AI layer that is permission-aware.

Ask Attio explicitly positions itself as enforcing existing permissions, so people only see what they’re supposed to see, and the human remains in control of suggested actions.

And Attio MCP matters because it’s the cleanest “AI meets system of record” bridge I’ve seen so far. It is a hosted MCP server, OAuth-authenticated, designed to give AI tools access to your workspace with confirmation on writes, and it is built for AI assistants to read and act on CRM data without turning your CRM into a DIY integration science project.

This is also where the “build vs buy” argument gets more interesting.

For most teams, the right move is not:

Build a CRM vs buy a CRM.

It’s:

Buy a system of record, then build the missing surfaces around it.

Retool has been making this point for years in the internal-tools world: keep Salesforce or HubSpot as the system of record, and build focused apps (deal review dashboards, commission calculators, renewals control centers) on top of CRM data via APIs.

With Attio, that “build around it” story gets even cleaner because the platform is already oriented around flexibility, strong permissions, and modern integrations. Attio has been shipping directly on these themes recently (MCP server, upgraded permissions, Ask Attio).

What about true counterexamples

Do I think vibecoded CRM replacements will exist? Yes.

Do I see a clearly evidenced, production-grade, secure-and-scaled example today? Not really.

I can verify that Atonom claims to be running a Lovable-built CRM in place of Salesforce for a relatively small team, and that claim is documented both by Lovable and by Atonom leadership.

What I can’t verify from public sources is the “enterprise-grade” part: the app-level threat model, permission architecture, audit logging, penetration testing, and how it behaves after the tenth integration and the hundredth edge case. And Lovable’s own docs explicitly remind you why that gap exists: platform security does not replace your responsibility for application security.

So my position is simple:

If your goal is to replace spreadsheets and move faster this quarter, vibecode away.

If your goal is to build a CRM that can survive the next two years of complexity, start from a platform that already solved the last 20%, and use AI to extend it.

That’s the bet behind building on Attio, then vibecoding the pieces around it.