Anthropic uses Salesforce. Lovable uses HubSpot.

These are companies that could build a custom CRM before lunch. They employ some of the best engineers alive. They have access to the most advanced AI models. They literally make the tools the rest of the market uses to generate code.

And every month, they pay their SaaS license like everyone else.

That should make you pause. Not because there’s anything wrong with building custom software — sometimes it’s exactly the right move. But because the world’s most technically capable companies are deliberately choosing not to build certain things. And the reason isn’t laziness or lack of talent.

What I learned building a CRM I shouldn’t have built

Before we talk about Anthropic, let me talk about Word Magic Software.

In the 90s, my father and I founded Word Magic — a translation software company that started on DOS and eventually got featured by Apple. We had a solid technical team and, like any self-respecting software company, we decided to build our own order management system. An internal CRM, custom-made.

And it worked. It was exactly what we needed. Every field, every report, every workflow — designed for our process.

The problems came later.

CRM bugs competed for attention with product bugs. Every improvement to the order system was time not spent on the translation software — which was what we actually sold. We kept perfecting that internal system for years, and each year it got harder to maintain.

When we finally wanted to migrate to a more modern e-commerce platform, connecting the legacy CRM was so painful that we made a decision that sounds absurd in hindsight but felt like the most practical option at the time: we didn’t connect it. We put one person feeding it manually, full-time.

A system we built to save us work ended up creating a full-time job dedicated to compensating for its limitations.

That lesson stuck. Today at IQ Source we use an off-the-shelf CRM. Not because we can’t build something custom — we can. But because I learned firsthand that the real cost of an internal system isn’t in the development sprint. It’s in the years that follow.

Two cost curves that no longer move together

Here’s what changed in the last two years: the cost of building software collapsed. Cursor, Lovable, v0, Claude Code — these tools let a single developer produce in weeks what used to take a team of five several months.

But the cost of running software hasn’t moved.

Building	Running
One developer with Cursor can create a working CRM in days	SOC 2 certification still costs $40K+ and takes 4 months
Prototypes that took weeks now take hours	99.9% uptime SLAs require redundant infrastructure
Code gets generated faster than ever	Security patches don’t apply themselves
The first version ships fast and looks great	Integrations with 15 tools break silently
Demo day works perfectly	At 3am the alert fires and someone has to respond

That table is the trap. The left column keeps getting easier. The right column hasn’t changed. And the gap between them is exactly where months of work and budget get lost.

We wrote about a related pattern in our analysis of hidden costs when scaling with free tools — the same logic applies when you build your own tool: the visible cost is the sprint; the invisible cost is operations.

The question smart companies actually ask

When Anthropic decides to use Salesforce, they’re not answering the question “can we build a CRM?” — of course they can. They’re answering a different question:

Should our engineers spend time on this instead of working on Claude?

Every engineering hour has an opportunity cost. An Anthropic engineer working on an internal CRM is an engineer not improving Claude’s context window, or building the next version of Claude Code, or solving hallucination problems in production.

The cost of Salesforce isn’t just the license. It’s the liberation of talent toward where it actually matters.

This doesn’t only apply to AI companies. An industrial distributor in Costa Rica faces the exact same equation: every hour your best developer spends maintaining a home-built inventory system is an hour not spent automating your quoting process — which is probably where your real competitive edge lives.

Core vs. context: a framework that holds up

Geoffrey Moore, author of Crossing the Chasm, proposed a distinction I still use with clients at IQ Source: core versus context.

Core is what differentiates you competitively. What your customers choose you for over the competition. What generates direct value and justifies your price.

Context is everything else you need to operate but that doesn’t distinguish you. Payroll, CRM, invoicing, email marketing, server monitoring.

The rule is straightforward: build what’s core. Buy what’s context.

For Anthropic, Claude is core. The CRM is context. For Lovable, their app generation platform is core. HubSpot is context.

For your company? The answer changes, and it’s worth being honest about it. I’ve seen companies insist that their internal reporting system is “strategic” when it’s really an inherited habit that nobody dared question.

An exercise we run with clients: list every internal system and for each one ask — if a competitor had this exact same tool, would you lose competitive advantage? If the answer is no, it’s context. Buy it.

When building IS the right call

I don’t want this to read as “always buy.” Building makes sense in specific situations:

The process IS your competitive advantage. If your dynamic pricing algorithm is the reason customers pick you, don’t stuff it into a generic SaaS. Build it, protect it, improve it.

No SaaS covers your workflow. Sometimes the process is so specific to your industry or operation that no product on the market solves it without distorting it. In that case, building can be cheaper than forcing a SaaS to do something it wasn’t designed for.

Data sensitivity demands it. In certain industries — healthcare, finance, defense — full control over where data lives and who accesses it isn’t optional. If your legal team can’t sleep at night with data in a third party, build.

Integration cost exceeds build cost. If connecting the purchased tool to your existing stack requires more work than building the functionality from scratch, the math is clear.

The decision isn’t philosophical. It’s arithmetic with risk variables.

In our post about the questions AI doesn’t ask we covered a related pattern: vibe coding tools make building feel complete, but the questions nobody raised — security, maintenance, scalability — are exactly what turns a functional MVP into long-term technical debt.

For Latin American companies, the equation weighs heavier

In our experience at IQ Source working with B2B companies in the region, the argument for buying context is even stronger.

Teams are smaller. A senior developer in San José, Bogotá, or Mexico City who spends three months building and maintaining an internal CRM is, in many cases, 20-30% of the company’s total technical capacity. In a 200-engineer company in San Francisco, that cost gets diluted. In a team of 5 to 15 developers, it’s an existential decision.

Sequoia Capital has argued that services are the new software — that the next big company will sell outcomes, not tools. For B2B companies in the region, that means the differentiator won’t be having a prettier CRM. It will be how fast you can deliver value to your client with the tools that already exist.

Every engineering hour spent replicating what HubSpot or Salesforce already solved is an hour not invested in what makes your company different.

---

The paradox of Anthropic paying Salesforce isn’t a contradiction. It’s strategic clarity.

The most capable companies in the world don’t build everything they can build. They build what they must build — what makes them unique, what differentiates them, what justifies their existence in the market. Everything else, they buy.

If your technical team is spending a significant chunk of its time maintaining systems that aren’t your product, the question isn’t whether you can keep going. It’s how much it’s costing you in opportunities you’re not pursuing.

At IQ Source we help B2B companies map their technology stack into core vs. context — and make the decision with data, not inertia. If you want to run that exercise with your team, let’s talk.