Buyer guide
Should you build your own CRM?
AI made the first version of a CRM cheap to write, so the build-versus-buy question is open again. This sets out what a CRM actually contains once other people depend on it, names the cases where building genuinely wins, and is honest about which of them apply to you.
The short answer
Build if the CRM encodes something your business does that nobody sells, and you can fund an owner for it every year. Buy if what you need is contacts, companies, deals, activity history, and reporting, which is what most teams mean when they say CRM.
The reason the question feels different in 2026 is that a model can now produce a working contact database in an afternoon. That is real, and it is not the part that was ever expensive. The expensive part starts the day someone else depends on it.
One question decides it, and it is not a cost question: can you name the team that owns this system in year three, with it on their roadmap? If you cannot, the rest of the analysis is academic.
Why this is being asked again
The build-your-own case is the practical conclusion of a bigger argument: that SaaS is finished because models can write the software. We checked that argument against evidence on a separate page, SaaS is dead: five claims, checked. The short version is that the subscription is not dying but the seat is under real pressure, and none of that settles whether you personally should build.
What did genuinely change is the shape of the cost curve. Writing the first version got dramatically cheaper. Owning the tenth version did not. As one engineering leader put it in a 2026 Retool report, when anyone can ship a tool in an afternoon, nobody signs up to maintain it. That sentence is the whole build-versus-buy decision in 2026.
What a CRM actually contains
A CRM is not a table of contacts. It is a set of subsystems that only look optional until somebody else depends on them. Below is the scope, with the part that costs more than it looks.
This list is our engineering judgement, not a survey. We deliberately have not attached vendor counts or prices to it: we hold a CRM pricing dataset, we audited it before using it here, and it was not clean enough to publish figures from. The reasoning is on the SaaS is dead page under Method. A hand-written list that says it is hand-written beats a table that implies a precision we cannot back.
| Area | What it means | The catch |
|---|---|---|
| Records and relationships | Contacts, companies, deals, and the links between them. | The links are the hard half. One contact at two companies, a deal with five stakeholders. |
| Activity history | Every email, call, meeting, and note, on the right record. | Matching an inbound email to the right contact and deal is a whole subsystem. |
| Permissions and roles | Who can see and edit what, per record and per field. | Retrofitting row-level security onto a working schema is close to a rewrite. |
| Import and deduplication | Getting existing data in, and keeping it from splitting into duplicates. | Nobody budgets for this and everybody needs it in week one. |
| Search and filtering | Saved views, filters across related records, sensible sorting. | Fast filtering across joins is where the naive schema stops scaling. |
| Reporting and dashboards | Pipeline by stage, forecast, activity, whatever the board asks for next. | The requests never stop, and each one is a new query nobody owns. |
| Audit trail | Who changed what, when, and what it was before. | Cheap if designed in on day one. Expensive and incomplete if added later. |
| Access and identity | Login, session handling, and removing access when someone leaves. | Security review will ask about SSO. A password list does not survive that question. |
| Integrations | Email, calendar, and whatever runs your actual operation. | Each one is a permanent maintenance commitment to somebody else’s API. |
| Backup and restore | Point-in-time recovery, tested at least once. | An untested backup is a belief, not a backup. |
| Notifications and reminders | Telling people what needs attention, without becoming noise. | The tuning is endless and it is what decides whether anyone uses the thing. |
| Second environment | Somewhere to test a schema change that is not production. | Skipping it works right up until it does not. |
Notice what is not on the list, because no vendor sells it separately: uptime, and somebody to call at 09:00 on a Monday when the pipeline view is blank. Those are not features. They are the reason software costs money.
The parts every build forgets
Three of them, and they share a shape: a prototype never has them, and none can be bolted on cheaply later.
Access revocation
The moment your CRM holds customer data, someone will ask how access is removed when a person leaves, and how you prove it happened. That is SSO, roles, and an audit trail, and it is a fortnight of work you did not plan.
Keeping data clean
One person writing to a database keeps it tidy. Five people writing to it produce duplicates, half-filled records, and three spellings of the same company within a month. Deduplication is a permanent job, not a launch task.
A second environment
Testing a migration on live customer records is fine until the day it is not. A seeded staging copy is unglamorous, always the first thing cut, and the reason the outage was recoverable.
The cost that arrives later
Build estimates are usually honest about the build and silent about the decade after it. Development agencies commonly quote a custom CRM at roughly $30,000 for something basic and $200,000 or more for an enterprise build, with annual maintenance at 15% to 25% of the build cost and hosting on top. Those are their numbers, not ours, and they are worth taking as a floor rather than an estimate.
The figure that matters more is the split. Maintenance is the majority of a system's lifetime cost, commonly put at 60% to 80% in software engineering literature. AI has cut the first slice and left the larger one intact, which is why a build that looks cheap in month one so often looks expensive in year three.
What AI made cheaper
- The first working schema and CRUD screens
- Boilerplate: forms, tables, filters, exports
- One-off scripts and internal glue
- Migrations and field mapping
What it did not touch
- Deciding what should happen, which is the actual hard part
- Keeping data clean once several people write to it
- Security review, access revocation, audit trail
- Being on call when it breaks, for years
The owner problem
Every internal CRM has one person who understands it. The build survives exactly as long as that person stays interested, and then it becomes the thing nobody will touch. This is the failure mode, not a budget overrun: the system does not collapse, it quietly stops changing while the business keeps changing around it.
Before deciding to build, write down the name of the person who owns it in year three. If you cannot, you have your answer.
The case everyone cites
Klarna is the example in every build-your-own argument, so it is worth reading past the headline. In early 2025 the company announced it was ending its use of Salesforce and Workday alongside a large AI programme. That much is accurate and it was a genuine decision by a real business at scale.
Two things followed. By May 2025 the CEO said the cost-cutting had gone too far and the company began rebuilding human customer service, citing falling quality scores. And reporting from CX Today indicates that what replaced Salesforce and Workday was substantially other vendors' software alongside in-house work, not a pure build.
The lesson is not that Klarna failed. A company that size, with that engineering budget, is exactly who should consider building. The lesson is that even there the outcome was a mix, and the part that got walked back was the part that assumed software could absorb the judgement of the people using it.
A real company replaced its enterprise SaaS with software it built itself
Partly trueKlarna did leave Salesforce and Workday, which is the strongest evidence the build case has. Reporting indicates the replacement was substantially other vendors' software plus in-house work, and the human side of the programme was reversed within months.
When building is the right call
There are real cases. They share a shape: the software encodes something specific to how you make money, and you already run engineering as a permanent function.
- Your process is the product. A lending desk, a clinical trial coordinator, a freight broker. The workflow is regulated or proprietary and no vendor models it, so configuring around the gap costs more than closing it.
- The CRM is a thin view over a system you already own. If the real data lives in your platform database, a bought CRM is a second copy to keep in sync. A view is cheaper than a sync.
- Scale makes the seat maths absurd. At several thousand light users, per-seat pricing stops being sensible and nobody will sell you a flat rate. This is a genuine and growing case.
- You have a funded owner, not a volunteer. A named team with the tool on its roadmap. Not a side project belonging to whoever built the prototype.
When it is not
- The reason is price. A build has to beat the subscription for years, not months, and it has to beat it after maintenance. For a small team the licence is usually a few thousand a year. Very little gets built AND owned for that.
- The reason is that the demo worked. A prototype proves the easy 20%. The remaining 80% is permissions, edge cases, imports, and the second user.
- The reason is one missing feature. Check whether an API, a webhook, or a custom object closes the gap. Rebuilding a system to add a field is an expensive way to add a field.
- Nobody has named the year-three owner. This is the one that decides it. Every other objection has a workaround.
Buy the record, build the edges
The choice is rarely all or nothing, and the split that works is usually the same one: buy the system of record, build the thing that is specific to you on top of it. You get backups, access control, audit trail, imports, and support from a vendor whose job that is, and you keep the part that is actually yours.
Three routes teams actually take, and where each one ends up.
The old way
- 1Buy a CRM as the foundationSalesforce
- 2Buy a tool for each gap, then wire them togetherClayApolloReplyDocuSignJiraMailchimpZapier
- 3Live with a fragile chain and data that is never quite complete
The recent way
- 1Build the CRM with a modelOpenAIAnthropic
- 2Build the outreach tooling the same way
- 3Discover the backlog, and that maintenance is now your core business
- 4Hit the point where too much is broken to keep up
- 5Buy the CRM you were replacingHubSpot
The way we build for
- 1Buy the system of record
- 2Keep sales and delivery in one place, and connect the sensitive infrastructureStripePlaid
- 3Tailor it and add what your team actually needs
- 4Pay for one licence rather than ten
- 5Add viewers without adding seat cost
Buy
Contacts, companies, deals, activity history, permissions, audit, reporting, imports, backups. Nothing here is differentiating and all of it is expensive to own.
Build
Your scoring model, your pricing logic, the integration with the system that runs your actual operation. Small surfaces, high specificity, real advantage.
Connect
A documented API and an MCP surface so your own code, and an agent, can read and write the record without anyone sitting in a form.
This is the shape Lumenbase is built for, and we would rather say so plainly than pretend to be neutral. The REST API and MCP surface exist so the record is programmable, Portage exists so moving data in or out is not a hostage situation, and the cost calculator runs the seat maths so you can check the buy side against a build estimate.
A five-question test
Answer these before writing any code. Three or more "no" answers means buy.
- 1Does the CRM encode a process that is specific to how you make money, rather than a general sales process?
- 2Can you name the team that owns it in year three, with it on their roadmap?
- 3Have you costed security review, access revocation, backups, and a tested restore?
- 4Is the build cheaper than the seat price over five years, including the maintenance share?
- 5If the person who builds it leaves next quarter, does it survive?
If you are buying, how to evaluate a CRM covers the shortlist, and what a CRM is covers the basics if this is your team's first one.
Method and limits
The scope list is judgement, not a survey. It is what we have found a CRM needs once more than one person writes to it, drawn from building one. We hold a public CRM pricing dataset and originally costed this page from it, then audited it and found the pricing fields were not reliable enough to publish figures from. The detail is on the SaaS is dead page under Method. So there are no vendor counts or price medians here, on purpose.
Build costs are other people's numbers. The $30,000 to $200,000 range, the 15% to 25% annual maintenance, and the 60% to 80% lifetime maintenance share are industry estimates from development agencies and software engineering literature. We have not audited them and they are best read as a floor. The Klarna sequence is reported by the outlets named in that section.
- No two builds are the same size. Treat the scope list as a checklist to price against your own case, not as a quote.
- We sell a CRM. That is a reason to read the "when building is right" section closely, and we have tried to make it genuinely useful rather than a straw man.