Forty Years of CRM, and the Year the Argument Changed

Ask how customer software evolved and you will usually get three beats: it started on MS-DOS, then Salesforce moved it to the cloud, and now some companies build their own. That story is roughly the right shape, and almost every specific in it is off.

I went and checked, because I sell custom software and I did not want to write a history that flattered my own business. What I found is a better story: four distinct eras, each one solving the previous era's real pain and creating a new one, with the same build-versus-buy argument recurring at every transition in slightly different clothes. Knowing which turn of that wheel you are standing on tells you more about your own decision than any feature comparison will.

Before the software: 1967

The idea predates the category by about twenty years. Robert and Kate Kestnbaum founded a direct-marketing consultancy in 1967 and are generally credited with developing customer lifetime value — applying financial modeling to the question of which customers were worth keeping. No software. Just the observation that a customer is an asset with a value you can calculate, which is the premise every product since has been built on.

Era one: the pop-up on a beige PC, 1984–1992

The DOS part of the story is true. The usual attribution is not.

The first hit was Borland Sidekick in 1984 — a terminate-and-stay-resident utility that popped a calendar, calculator, address book and phone dialer over whatever you were already running. It was not sold as customer software. It was sold as a way to look someone up without losing your work, which in 1984 was genuinely novel.

TeleMagic came next. Michael McCafferty wrote it in early 1985 in dBASE II, at night and on weekends, originally as a roughly $5,000 custom job for one San Diego customer — an office coffee service. It became a product afterwards. The first real contact manager was a bespoke build for a single client, which is a detail I enjoy more than I should.

ACT! — the product usually named as the origin — arrived in 1987 at $395, from Conductor Software in Irving, Texas. Third, not first, by three years. It was renamed Contact Software International around 1988 after the positioning consultant Jack Trout pointed out that “Conductor Software” sounded like products for musicians.

GoldMine followed in 1990, built by Jon Ferrara and Elan Susser, who had founded their company in 1989 with $5,000 to sell accounting software. GoldMine started as an internal sales tool one founder wrote for the other — again, an internal build that escaped.

What this era solved: the Rolodex. Your contacts became searchable, and something could remind you to call back.

What it created: every salesperson's contacts lived on that salesperson's machine. When they left, so did the relationships. The data was personal, not organizational.

Era two: client-server, and the part everyone skips, 1993–2000

This is the generation the popular telling jumps straight over, and it is where most of the surviving scar tissue about enterprise software actually comes from.

Networked versions arrived early — ACT! for DOS 2.0 added network support in August 1990, nine years before Salesforce existed — but the era belongs to Siebel Systems, founded in 1993 by Thomas Siebel and Patricia House, both ex-Oracle. Their first product shipped in 1994 at $3,500 to $6,500 per seat. The growth is worth seeing laid out:

Somewhere in here the label “CRM” appeared, and nobody can prove who coined it. At least six parties claim it. Siebel's own products in 1994–95 were called “Sales Information System” and “Sales Enterprise.” The analyst Chris Selland, who covered the market at the time, reckons Gartner coined it to categorize vendors, with Tom Siebel an early adopter rather than the author: “Since Gartner was (and is) the biggest, their term won.” The defensible statement is that the label emerged around 1995 and hardened by 2000.

What this era solved: the data became the company's. Shared, on a server, surviving the salesperson's departure.

What it created: the six-figure implementation. You bought licenses, then paid consultants for months to make the thing match your business. Customisation was the product's chief selling point and its chief cost, and the customizations made upgrades expensive — which is the exact trap people are still describing today in different words.

Era three: no software, 1999–present

Salesforce was incorporated in February 1999 in a rented apartment on Telegraph Hill by Marc Benioff, Parker Harris, Dave Moellenhoff and Frank Dominguez, and launched publicly in February 2000 at an event called “The End of Software.” They famously hired actors to picket a rival's conference — the origin of the red circle-slash “No Software” logo.

The pitch was not really about the cloud. It was about the implementation. No servers, no six-month consulting engagement, a credit card and a browser. It was aimed squarely at the pain era two created.

The era filled in around it: Microsoft shipped its first CRM in January 2003 (the “Dynamics” brand did not exist until 2005); HubSpot, founded in 2006, did not launch a CRM until 2014 — eight years in, and free; Pipedrive started in Tallinn in 2010. Salesforce finished fiscal 2026 with $41.5 billion in revenue and 83,334 employees, and has been IDC's top-ranked CRM by revenue for thirteen consecutive years, at 20.0% share.

What this era solved: implementation risk and capital cost. You could be running by Friday.

What it created: a per-seat bill that never stops, and a new kind of lock-in — not the servers, the configuration.

Let me kill the statistic before it gets used on you

Anyone arguing for a custom build will eventually tell you that most CRM projects fail. I am the sort of person who benefits from that claim, so I went to find its source. It does not hold up, and it is worth knowing exactly how it broke.

Gartner's actual published line was a prediction: “Through 2006 more than 50 percent of all CRM implementations will be viewed as failures from a customer's point of view.” The commonly quoted 80% figure, Gartner's Scott Nelson told CRM Magazine, “only applies to sales automation implementations” — adding that it “was not one monolithic quantitative study. It was pieces of studies put together.”

The 55% version has an even clearer origin. Gartner's Ed Thompson explained in a 2004 interview that it came from a late-2001 study of 500-plus organizations asking “did it meet expectations?” In his words: “people took our statement: ‘failed to meet expectations,’ and they chopped the ‘meet expectations’ off it and just said, ‘failure.’”

The real distribution he gave: about 5% absolute successes, about 40% met expectations, about 40% somewhat successful but short, about 10% somewhat unsuccessful, about 5% absolute failures. Asked directly whether 55% was the failure rate: “No, I don't, because it's not absolute failure. And if you're looking at absolute failure, you're looking at 5 percent, maybe.”

So: buying a CRM mostly works. If someone uses the failure statistic to sell you a build, you have learned something useful about them.

Era four: the long tail builds its own, roughly 2017–now

What is genuinely new is not that companies are leaving Salesforce. It is that the floor under building dropped. Airtable (2012), Notion (2013), Retool (2017) and now AI coding tools mean a small company can produce something workable in weeks rather than quarters. None of those three is a CRM; all three are used to build one.

Be careful how much weight this bears. Retool's 2023 survey of 2,276 developers and technical leaders found 55% use home-grown internal applications — but 48% also use spreadsheets, and on direction respondents split near-evenly, 37% wanting to consolidate tools against 31% wanting to buy more. This is a fourth option for the long tail, not a migration. Next to a $41 billion vendor it is commercially small.

What buying actually costs, in 2026

The honest build-versus-buy comparison needs a real number on the buy side, and the sticker price is not it. Salesforce Sales Cloud list, as of this month:

Three things about that table matter more than the numbers in it.

API access is an add-on below Enterprise. Salesforce's own comparison table prices the Web Services API at an extra $25 per user per month on Pro — taking a $100 seat to $125, a 25% increase to make the system programmatically integrable at all. On the cheaper tiers it is not available at any price. If your plan involves connecting the CRM to anything, price that in from the start.

Support and environments are priced as a percentage of what you already spend. Premier Success is 30% of net license fees; a Full Copy sandbox is another 30%. Fifty Enterprise seats with both is $105,000 + $31,500 + $31,500 = $168,000 a year, about 1.6× the list price you were quoted.

The features people picture are add-ons on top. Revenue Cloud (quote-to-cash) starts at $200 per user per month, Revenue Intelligence at $220, Agentforce for Sales at $125. An Enterprise seat plus Revenue Cloud is $375 per user per month — $4,500 per user per year. And list prices move: on 1 August 2025 Salesforce raised Enterprise and Unlimited by an average of 6%, Enterprise going $165 to $175.

None of that makes buying wrong. It makes the comparison real. Under about 25 seats, the license total is rarely large enough to justify a build on price alone — and price should never be the only reason to build anyway.

The same argument, every era

Look down that last column. Every era's build case was an argument about cost, and every era's build failure was an argument about ownership. For forty years the cost argument was wishful and the ownership argument was decisive, which is why buying kept winning.

Both halves moved in 2026, and they moved in the same direction.

The cost argument stopped being wishful. “We can do it in a weekend” was a fantasy in 2017 because the boring forty — contacts, companies, deals, stages, permissions, audit trails, search, imports, notifications — genuinely took months. That scaffolding is now fast to produce. Not free, not thoughtless, but fast enough that the generic part of the system stopped being the expensive part.

And the ownership argument got cheaper on the same curve. The reason a custom CRM died in year three was never a dramatic failure; it was that changing it required a developer who had moved on. When a change that used to be a two-week ticket is an afternoon, the maintenance burden that killed every previous generation of build stops being the thing that kills it.

Meanwhile the other side of the ledger went the wrong way. Per-seat pricing kept climbing and it scales with headcount whether or not value does — a seat costs the same for the person living in the system all day and the one who opens it twice a week to update a field. At published rates for a serious CRM, a hundred seats runs six figures a year, every year, and at the end of five years you own nothing.

So the argument really is the same one, every era. What changed is that this is the first era where the side making it is right.

So: should you build one?

Work it top to bottom. This used to be a gauntlet that mostly ended in BUY; it is a router now, and both ends of it are good outcomes. The gates that still stop a build stop it for reasons that have not moved — an ordinary process, a problem that is really about integration, and nobody to own the result.

Two gates deserve more than a box.

Gate 3, the thin layer, is the answer people reach for least and need most. Keep the vendor CRM as the system of record; build only the piece that does not exist — the quoting screen, the scheduling logic, the report nobody can produce. You keep the ecosystem, the security posture, and the ability to hire someone who already knows the tool, and you get the fit. It is also far cheaper to reverse than a full build.

Gate 6, ownership, kills most builds, and it kills them correctly. Custom software does not fail loudly. It quietly stops being updated when the person who understood it changes role, and three years later it is the reason you cannot change a process. If you cannot name the person or firm responsible for patches, upgrades, tested backups and the bus factor for the next five years, the honest answer is buy — and “we'll figure out support later” is a decision to abandon the asset, made early.

Where custom genuinely wins

Wider than it was two years ago, and still not universal:

• The workflow is the business. Pricing rules, routing, underwriting, scheduling, compliance logic — things that are your actual advantage rather than support for it. If your pipeline is stages, tasks and email, you will never out-build a company whose entire payroll is that one problem.
• A hard external constraint. Data residency, air-gapped operation, a client contract clause, a regulator. The cost comparison ends because the cheaper option is not available to you.
• Seat count. This is the bar that moved furthest. It used to take several hundred users before the license total justified a build; at current seat pricing against current build costs it is a great deal fewer, and the arithmetic is now worth running rather than assuming.
• The integration is the point. When the value is in joining the CRM to systems that have no connector and never will.
• The process is genuinely yours, at any size. The newest case, and the one with nothing to do with scale. A six-person firm will never make the seat arithmetic work — six seats is not real money — but shaping software around a process that is actually particular to them now costs a sum that would have been absurd three years ago. Small teams arrive here through cheap scaffolding, large ones through expensive rent. Same destination, opposite arithmetic.

And where it loses: generic sales pipelines, anything where you need the vendor's compliance paperwork to answer a customer questionnaire, anything where you need to hire experienced people off the open market quickly, and anywhere email deliverability matters — that alone is a specialist problem most builds badly underestimate.

The pattern worth carrying away used to be that you are not replacing a feature list — you are replacing a maintenance department and a labor market, and reproducing those is the expensive part. That was true, and it is the sentence that correctly killed most builds for two decades.

It is doing less work than it used to. The maintenance department is smaller because changes are cheaper to make, and the labor market matters less when what gets handed over is something a competent generalist can keep running. What remains of the warning is real and much narrower: do not reinvent an inbox, do not rebuild deliverability, and do not start without knowing who owns the result. Inside those lines, the thing that was reckless in 2024 is now ordinary.

If you want help with this

I should be straightforward about my position: building custom CRMs and the systems around them is work I do and want more of. Which is why it matters that the tree above still has four separate gates that end in “buy”. A build sold to someone who should have configured a vendor product is a bad project for both of us, and I would rather tell you that in week one than month five.

What I will not do is pretend the answer is what it was in 2024. For twenty years the responsible advice was buy and bend, and I gave it. The arithmetic underneath that advice has changed, and repeating it now out of habit would be its own kind of dishonesty.

Where I am genuinely useful is the two outcomes in the middle. The thin layer — keep Salesforce, HubSpot or Dynamics as the system of record, and build the screen, the integration, or the reporting the vendor will not do. And the scoped custom build, for the businesses whose workflow really is the product, kept deliberately narrow: build the differentiated part, leave contacts, email, calendar and documents on commodity infrastructure. A custom system that also reinvents an inbox is how these projects die.

If you are somewhere in this decision, the most useful thing you can bring is gate 1 — the one paragraph describing the workflow no vendor supports, and what doing it by hand costs you a year. Bring that and we can usually tell inside half an hour whether you need me or a better-configured version of what you already own. Here is what that looks like as an engagement, or describe the situation with the button below. I usually reply the same day.