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:
| Year | 1995 | 1996 | 1997 | 1998 | 1999 | 2000 |
|---|---|---|---|---|---|---|
| Siebel revenue | $8M | $39M | $120M | $392M | $791M | $1B+ |
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 myth worth correcting: Salesforce did not kill Siebel. When Oracle announced its $5.85 billion acquisition of Siebel in September 2005, Siebel's 2004 revenue was $1.34 billion against Salesforce's $176 million — roughly eight times larger. Siebel's stall is attributed to the 2001 recession and heavy exposure to telecom customers who stopped buying. The cloud-disruption narrative was fitted afterwards, because it makes a better slide.
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:
| Edition | Per user / month | 50 seats / year |
|---|---|---|
| Starter Suite | $25 | $15,000 |
| Pro Suite | $100 | $60,000 |
| Enterprise | $175 | $105,000 |
| Unlimited | $350 | $210,000 |
| Agentforce 1 Sales | $550 | $330,000 |
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
| Era | Solved | Created | The build case then |
|---|---|---|---|
| DOS contact managers | The Rolodex | Data owned by individuals | “Ours is just a dBASE file” |
| Client-server | Shared company data | Six-figure implementations | “Cheaper than the consultants” |
| Cloud | Implementation risk | Perpetual per-seat cost | “Cheaper than the subscription” |
| Build-your-own tooling | Cost of building | Who maintains it in year three | “We can do it in a weekend” |
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. That has never changed, and it is why the ownership gate below is the one that decides most of these.
So: should you build one?
Work it top to bottom. Most businesses stop in the first three gates, and stopping early is the cheap outcome.
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
Narrower than the people selling it suggest, and real:
- 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 at scale. Several hundred users of a system where each one needs a fraction of what a full license provides.
- The integration is the point. When the value is in joining the CRM to systems that have no connector and never will.
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 is 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.
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. That is exactly why the tree above sends most readers to “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.
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 I build and run, or describe the situation with the button below. I usually reply within a day.