Pulse
All writing

October 10, 2026

You don't need Salesforce if you have Claude. Or do you?

AI is changing the economics of building software, and I'm starting to question how much enterprise software companies will actually need to buy.

Infographic. Left: separate applications for sales and CRM, finance, HR, projects, IT operations, analysis, email and creative work, with the problems they cause: siloed data, switching between apps, inconsistent information, manual handoffs and duplicate work, and high subscription and administrative costs. Center: one business operating dashboard with revenue, pipeline, margin and utilization, AI insights and recommended actions. Right: faster decisions, a more complete view, less busy work, built around your business, lower total cost, and the same governance. Bottom: see the problem, understand it, evaluate options, take action, track the results.

I've been spending a lot of time lately building things with Claude: dashboards, integrations, workflows, whole applications. Some are fairly simple. Others turned out more sophisticated than I expected. The more I build, the more I question something I've taken for granted for most of my career: why are we paying so much for enterprise software?

Salesforce, NetSuite, ServiceNow and Adobe are good products. They've spent decades building sophisticated platforms, and there's a reason companies pay billions of dollars to use them. My question is about something else. If AI makes it dramatically easier to build software, at what point does buying it stop making economic sense?

That's a broad question, so I'll start with something familiar: Salesforce.

Do you actually need Salesforce?

Think about what most companies use a CRM for: accounts, contacts, opportunities, pipeline stages, activity tracking, forecasting and reporting.

Salesforce does considerably more, of course. There's territory management, complex permissions, workflow automation, analytics, integrations, and an enormous ecosystem of applications and partners. But how much of that does the average company use? And how much of what it uses is genuinely hard to recreate?

A CRM is a collection of data, business rules, workflows and interfaces. None of those ideas is especially complicated. What made the decision easy for so long was that building and maintaining software was expensive. You needed developers, architects, designers, testers, infrastructure and ongoing support, and even fairly simple applications took real investment. Buying Salesforce made sense.

I've now built applications with Claude that would have taken far more time and specialized people not long ago. That doesn't make me a software engineer, and not everything Claude produces is ready for production. It does change what's possible.

If I can build a CRM that does exactly what my company needs, connects directly to our other systems and costs substantially less to run, why wouldn't I consider it? I'm not about to cancel Salesforce tomorrow. For the first time, though, the alternative feels realistic enough to evaluate.

The argument for building

I see three reasons to take this seriously.

First, most companies don't use every feature they pay for. Enterprise software has to serve thousands of customers with different requirements, which means broad functionality, extensive configuration and layers of complexity. A professional services firm might need a fairly simple set of sales capabilities: manage accounts, track opportunities, forecast revenue, connect contracts to delivery and watch renewals. Why couldn't those live in a system built around how that company actually works?

Second, cost. Salesforce Enterprise has a published price of $175 per user per month, billed annually. That's the price I could find when I wrote this, and it has likely changed by the time you're reading it, so treat the math as an illustration. For 50 users that's $105,000 a year in subscriptions, before add-on products, implementation services or anything else. Over five years it comes to $525,000 at that rate, assuming licensing and pricing don't change.

Now imagine building a purpose-built CRM for $150,000 and running it for $50,000 a year. Those numbers are hypothetical, not an estimate of what every company could do, but they show why the conversation is worth having. The custom system would cost $400,000 over five years against $525,000 in subscriptions, and you'd own the application.

That assumes the custom system meets the requirements, stays on budget and doesn't add operating costs of its own. Those are big assumptions. The comparison is just no longer automatically ridiculous.

The third reason interests me most: integration. In a professional services company, sales doesn't operate on its own. An opportunity becomes a contract, the contract creates delivery obligations, those obligations need people with the right skills and availability, and delivery creates costs, revenue and eventually renewals.

Yet we usually manage all of that in separate applications. Salesforce has the opportunity, another system has the contract, a project management platform has the delivery, and finance invoices out of the ERP. Then we build integrations and workflows to connect it all.

What if we started from the whole business process instead, and the CRM were one capability inside a larger operating system built around how the company earns revenue and delivers its services? That's a far more interesting proposition than a cheaper copy of Salesforce.

Building software isn't the same as operating it

This is where the argument needs some discipline. A CRM prototype is fairly easy to build with Claude. One a company can depend on is much harder.

Salesforce sells more than account, contact and opportunity records. It sells a mature platform with security controls, permissions, audit capabilities, APIs, availability commitments, integration options and years of accumulated functionality. When something breaks, a vendor is responsible for fixing it. When you build your own CRM, that responsibility is yours. Someone has to maintain the code, manage the infrastructure, protect customer information, test changes, watch performance, run backups and recover from failures. AI can help with a lot of that work, but the accountability stays with you.

AI-generated software can also look impressive while hiding architectural problems, security weaknesses, or assumptions that fall apart in real use. Claude can produce thousands of lines of code, and that says nothing about whether they're correct, maintainable or secure. I don't take that as a reason to dismiss AI-assisted development. It means treating it like engineering.

Then there's switching. A company that has spent ten years building its sales operation on Salesforce may have hundreds of custom fields, integrations, workflows, reports and dependencies. Replacing all of that could cost far more, and disrupt far more, than paying the subscription. For those organizations, building a replacement may be a terrible business decision. AI making something possible doesn't make it economical.

What it really costs to own

The comparison isn't Salesforce licensing against a Claude subscription, because Claude isn't the CRM. You still need databases, hosting, authentication, APIs, monitoring, business logic and some kind of user interface, plus model usage, maintenance, security and ongoing development. A credible comparison includes all of it, along with the value of the capabilities you're replacing.

If Salesforce costs $100,000 a year but replacing it takes $200,000 to build and $150,000 a year to run, you've gained flexibility and raised your costs. If you can build and run a purpose-built system for materially less while improving how the business works, that's a very different outcome.

Some of the costs never show up on a software invoice. How much time do employees spend entering the same information into several systems? How much effort goes into keeping integrations alive? How many people are involved in handoffs between sales, delivery and finance? How long does leadership spend reconciling reports because different systems tell different stories?

Those costs are real, even if they're hard to isolate. A purpose-built operating system might not win on license savings alone. It could win by removing the overhead that disconnected applications create, and that's where the business case gets much more compelling.

Salesforce isn't standing still

Neither are Microsoft, ServiceNow, Oracle, Adobe or the other big vendors. They're building AI into their platforms, exposing capabilities through APIs, and making it easier for agents to work with their systems. Salesforce has even announced integrations that bring its data and workflows into Claude.

That's a smart move. If people increasingly want to work with business systems through AI, Salesforce wants to stay the platform underneath, supplying the data and the business capabilities. For many companies that's exactly the right architecture: Claude handles the interaction and the intelligence, and Salesforce stays the trusted system of record. You get the benefits of AI without taking on the full job of building and running your own CRM.

It also raises a question. If Claude becomes the main way I manage accounts, review opportunities, update records and prepare forecasts, how much of the traditional Salesforce application do I still need? If I no longer depend on its interface, what exactly am I paying for: the data model, the workflow engine, the integrations, the security, the reliability?

Those all have value. The difference is that I can now evaluate them separately, and if I can reproduce the ones I actually need for less, the decision looks different.

What if the customer becomes the competitor?

For decades, enterprise software companies mostly competed with each other. Salesforce competed with Microsoft Dynamics, HubSpot and other CRM vendors. Adobe competed with other creative software makers, and ServiceNow with other workflow platforms. AI-assisted development adds a new competitor: the customer.

Most companies have no wish to become software companies. They don't have to. The cost and effort of building useful software are falling, so a company that had no realistic alternative to buying may now be able to build. It doesn't have to reproduce the whole commercial product, only the capabilities that matter to its business.

A professional services firm isn't trying to compete with Salesforce in the CRM market. It needs a reliable way to manage customer relationships and revenue. If it can build that economically, Salesforce has to justify why its subscription is still the better option, and that's a very different competitive dynamic.

It also changes how I think about software intellectual property. Software IP isn't becoming worthless. Proprietary algorithms, mature transaction systems, security capabilities, specialized data and complex business logic still carry real value. But the ability to create software functionality is becoming less scarce, and when something gets less scarce, you can expect pressure on what customers will pay for it. Not every SaaS company loses, but some of the advantages behind the traditional SaaS model may not last as long as they used to.

For professional services firms, the opportunity is bigger than replacing Salesforce

This is the part I keep coming back to. Imagine starting a professional services firm today, with no legacy applications, established workflows or existing technology investments. Would you immediately buy a CRM, an ERP, a project management platform, a resource management application, a service management system and a reporting platform? Maybe. I'd be tempted to do it differently.

I'd start by defining how the business operates. How do we win customers and price our services? How do signed agreements become delivery plans, and how do we assign people to them? How do we track performance and profitability, and manage renewals? Then I'd work out the capabilities those processes need. Some I'd buy, some I'd build, and some I'd automate with agents.

I'd probably still use a proven financial system; rebuilding a general ledger, accounting controls and regulatory functionality doesn't appeal to me. A CRM, resource management, project tracking and operational reporting are different. Those are areas where I'd seriously evaluate building, especially if the result were one operating environment connecting the whole customer lifecycle.

There's an organizational side to this too. We've spent years creating processes and roles around the limits of our software. People move information between systems, teams keep separate records, managers reconcile reports, and administrators configure workflows and manage permissions. Some of that work is necessary. Some of it exists only because our technology is fragmented, and if we remove the fragmentation, we may be able to remove that work with it.

I don't see that as replacing employees with agents. It's a chance to reconsider how much administrative effort it should take to run a business, and that's potentially worth far more than any savings on CRM licenses.

So, do you need Salesforce if you have Claude?

For some companies, absolutely. A large enterprise with complex sales processes, extensive integrations, demanding governance and years invested in Salesforce may have every reason to stay. For a smaller company with simple sales processes, little customization and the ability to support a purpose-built application, the math could come out very differently. And for a new professional services firm starting from scratch, I think the case for building at least some of its own operating capabilities keeps getting stronger.

Claude doesn't replace Salesforce by itself. It changes the cost and practicality of building an alternative, and that might be more disruptive than another CRM vendor entering the market.

For most of my career, the conventional wisdom was to buy software rather than build it unless you had a compelling reason. That made sense when development was expensive and established platforms offered capabilities that were hard to reproduce. The assumptions behind that advice are changing.

I'm not convinced companies should start canceling their enterprise subscriptions. I am convinced we should stop assuming those subscriptions are the only practical option.

“The biggest threat to enterprise SaaS may be customers discovering they can build more of what they need themselves.”

Not everything, not without risk, and certainly not for free. But enough to make the old build-versus-buy decision a lot more interesting than it used to be.

See what your CRM already knows.

A Pipeline Truth Audit reads it, read-only, and shows you in one week.

Get your Pulse