Salesforce versus custom CRM: when is your own system cheaper?
Salesforce has been the world's most widely used CRM platform for years for good reason. The ecosystem is vast, the functionality deep and the mobile app mature. Yet we increasingly see companies with 30 to 200 users working out what their Sales Cloud or Service Cloud will cost over five years, including admin hours and consultancy, and then seriously considering a custom CRM. This article explains honestly when that calculation tips and when Salesforce remains the sensible choice.
Discuss your CRM case To the cost comparisonWhen Salesforce licences and admins cost more than building your own CRM
The licence price on the website is rarely the whole story. For a fair comparison, count licences, an in-house or external Salesforce Admin, periodic consultancy for Apex and Flow changes, AppExchange packages, sandboxes and data migration costs. Work out the TCO over five years and the outcome surprises many boards.
A typical B2B company with 60 sales and service staff pays a fixed price per user per month for Sales Cloud Enterprise or Service Cloud Enterprise, and that price almost doubles if you want to upgrade to Unlimited or use Einstein features. On top of that come Sales Engagement, CPQ, Marketing Cloud integrations and various AppExchange add-ons, each charged per seat. In practice, we see total licence costs rise to several times the headline price once all the modules you need are added.
Beyond licences, a Salesforce Admin is almost always needed, either full-time in-house or through a partner. That role is no luxury: without someone who manages page layouts, writes validation rules, maintains Flow Builder, updates profiles and permission sets and promotes releases between sandboxes, any Salesforce org becomes unmanageable within a year. For more complex logic, an Apex developer joins, often at consultancy rates. A custom CRM also needs that role, in the form of a development team or software partner that continues to build out the system, and that budget can be negotiated up front.
The tipping-point question, then, is not "what does a licence cost?" but "what are our total CRM costs over five years, and how much of that scales with the number of users?" For a growing business with 80, 120 or 200 seats, Salesforce costs rise linearly, whereas a well-built custom CRM scales far more flatly: hosting, maintenance and further development do not grow one-to-one with user numbers. That is the fundamental economic reason why organisations eventually make the switch.
What truly makes Salesforce strong — and why that explains its dominance
Before we look at frustrations, it's worth acknowledging that Salesforce did not become the market leader by accident. Three things are hard to match, and it's important to name them honestly.
AppExchange ecosystem
Thousands of certified integrations and industry-specific packages — from DocuSign and Conga to vertical solutions for financial services, real estate and healthcare. Without your own development, you have access to a vast library of ready-made functionality.
Mature mobile Lightning app
The Salesforce mobile app has been continuously developed for years, with offline support, push notifications, geo-tracking for field service and an extensive permission layer. For sales and service teams who work outside the office, that is a serious advantage over many home-built CRMs.
Established declarative tooling
With Flow Builder, Process Builder (legacy), Validation Rules, Approval Processes and Lightning App Builder, advanced admins can configure a great deal of logic without writing code. For businesses without developer capacity, this is a legitimate productivity accelerator — provided the complexity doesn't get out of hand.
Enterprise security and certification
SOC 2, ISO 27001, FedRAMP, HIPAA readiness, granular sharing rules, role hierarchies and field-level security. For heavily regulated sectors, this compliance documentation stack is often decisive and hard to replicate in a custom build.
Einstein AI and Data Cloud
Lead scoring, opportunity insights, Einstein Bots, Einstein Activity Capture, Prediction Builder and the recent Data Cloud / Agentforce layer. Salesforce is well ahead in AI, although its pricing bears no relation to self-built alternatives with OpenAI or Azure AI integrations.
Partner and talent network
Thousands of certified Salesforce Admins, Developers and Architects are available worldwide. For an international organisation that needs support on several continents, that is a considerable advantage over a unique custom stack.
Six reasons businesses outgrow Salesforce
None of these is a knockout on its own. But once several start to pinch at the same time, management rightly asks: are we going to keep paying for functionality we don't really use, or should we build something that fits exactly?
1. Costs per seat rise disproportionately
Salesforce charges for almost everything per user per month. Sales Cloud, Service Cloud, CPQ, Sales Engagement, Field Service and most AppExchange packages are all seat-based. As a team grows, the CRM budget doubles without the feature set changing. In a custom build, licence costs are virtually absent; you pay for hosting, support and development, not for adding a twentieth account manager.
2. Vendor lock-in applies to processes, not just data
Getting data out via Data Loader or Bulk API is technically manageable. The real lock-in lies in the hundreds of Validation Rules, Apex triggers, Flows, Approval Processes and custom objects built up over years. Business processes have become intertwined with Salesforce-specific metadata, and translating that knowledge into another stack requires a serious migration project.
3. Admin overhead for a moderately complex data model
A Salesforce Admin spends a great deal of time maintaining Page Layouts per profile, Lightning Record Pages per app, sharing rules across role hierarchies, and testing releases across Developer, UAT and Full sandboxes. For an organisation with a relatively simple data model, that feels like overhead: a custom CRM built on Postgres with clear domain models simply requires less context-switching for each change.
4. Customisations are slow and expensive
A seemingly small change, such as an extra field that flows through four reports, a Flow that talks to an external API, or a Lightning Component for a specific workflow, typically requires a Apex developer, a test class with sufficient code coverage, a deployment via SFDX or change sets, and a UAT cycle. In a well-designed custom CRM, a development team often delivers the same change in a fraction of the time, because it makes stack choices that suit your business.
5. EU data, privacy and data sovereignty
Salesforce operates EU data centres and offers Hyperforce regions, but some sectors (government, healthcare, financial supervision) are reluctant to place customer data with a US hyperscaler. A custom CRM hosted in a Dutch or EU data centre (for example with Leaseweb, Hetzner or Scaleway) makes data sovereignty and GDPR compliance easier to demonstrate. Until a few settlements are reached, this is a real argument in tenders.
6. UX that no longer fits how your team works
Lightning Experience is an improvement on Classic, but it remains a generic interface that must serve every industry and every workflow at once. Sales teams complain about the number of clicks needed for a single opportunity update, and service staff about case views that don't match their process. With a custom CRM, you design the screens precisely around the most common tasks, which in practice yields significant time savings and better data discipline.
A nuance we should be candid about: points 1, 3 and 4 can partly be resolved within Salesforce itself, by managing licences more tightly, by having an experienced Architect clean up Page Layouts and sharing rules, and by having a certified partner review automation. Not every Salesforce frustration needs to lead to a migration. But for organisations where three or more reasons are pinching at the same time, an honest business case for custom development is worth the effort.
When is custom development cheaper over a 5-year TCO?
The calculation depends heavily on the number of seats, the complexity of the data model, and the extent to which you use AppExchange packages and Einstein features. The variables below are the building blocks of a fair comparison. We always ask for concrete figures from your Salesforce partner or CSM, not from a price list on the website.
Salesforce side of the TCO
Per-user licence costs for Sales Cloud or Service Cloud (base edition), upgrades to Unlimited or Einstein bundles, AppExchange add-ons (often 5 to 15 in mature orgs), sandbox licences (Partial Copy and Full Sandbox are substantial), a Salesforce Admin (in-house or via a partner), Apex developer hours for releases and integrations, and MuleSoft or similar for ESB integrations if these are part of the architecture.
Custom development side of the TCO
One-off build costs (depending on scope and number of modules), hosting in an EU data centre, an ongoing development budget per quarter or year, monitoring and an uptime SLA, security audits (annually or after major releases), a backup and disaster recovery strategy, and an internal or external product owner who guards the roadmap and prioritisation. No seat-based licences, which is the structural advantage.
As a rough tipping point for custom CRM software, we see that the business case usually only becomes convincing from around 40 to 60 active users, or with a smaller team that has a strongly deviating data model where Salesforce customisations are relatively expensive. Below that threshold, you usually pay more for a custom build than for Salesforce, simply because the one-off build costs are not spread across enough seats. So be honest in your calculations: for 15 salespeople with a standard pipeline process, Salesforce Essentials or Pro is often cheaper than building your own.
What makes the calculation complex is that many "hidden" Salesforce costs only become visible after migrating to a higher edition: an AppExchange package that turns out to be indispensable, a second sandbox the development team asks for, a few hundred extra MuleSoft hours for an ERP integration. In a custom software RFP, you try to bring those costs into scope upfront, which is tighter but harder to predict perfectly. A good partner therefore works with a fixed-price MVP and a transparent rate for further development, rather than an open-ended consultancy engagement.
What a Salesforce-to-custom migration looks like in practice
A sensible migration rarely follows a big-bang approach. The pattern we see working again and again combines data export, parallel running, phased process cutover and, only at the very end, scaling down Salesforce licences.
Step 1: Data export and data model mapping
Using Data Loader or the Bulk API, you export Accounts, Contacts, Opportunities, Cases, custom objects, Tasks and Activities. At the same time, you document Validation Rules, Flows and Apex logic so the development team can reproduce the business rules in the new stack. Plan for a thorough discovery phase: the export itself is the easy part, while understanding what all those rules actually do is the real work.
Step 2: MVP of the custom CRM
First build the most-used 70 per cent of the functionality: account and contact management, pipeline, tasks, email integration and basic reporting. Full feature parity on day one would undermine the business case, so the edge cases follow in iterations once the first teams are live.
Step 3: Parallel run with synchronisation
Both systems run side by side for a few weeks, with two-way sync or daily delta imports. A first team (often one region or one business unit) works fully in the new CRM while the rest stay in Salesforce. This lets you test real-world performance, edge cases and adoption without business risk.
Step 4: Phased cutover per team
You migrate definitively per business unit, region or customer segment. Salesforce licences are scaled down pro rata at the next contract renewal, not earlier, so you do not waste budget on a half-finished solution. Communication, training and change management run in parallel.
Step 5: Rebuilding integrations
ERP integrations (Exact, Unit4, AFAS, SAP), email (Outlook, Gmail), telephony, marketing automation, finance: everything that used to hang off Salesforce via MuleSoft or point-to-point gets a new endpoint. Many organisations use this moment to modernise the integration layer into an API-first architecture that is easier to replace.
Step 6: Archive org or read-only export
For compliance and historical reporting, many organisations keep a scaled-down Salesforce org as a read-only archive, or export the full history to a data lake (BigQuery, Snowflake, Postgres). It is not glamorous, but it is essential for audit trails and long-term look-back questions from finance or legal.
A successful migration depends less on technology than on people-side change management. Sales teams that have worked in Salesforce for years have muscle memory and their own workarounds, and you need to take those seriously. Plan training sessions, office hours with the product owner and a feedback channel where users get an answer within 48 hours to "where is this field now?". For the integrations between the new CRM and surrounding systems, for example the transition to a Salesforce integration during the parallel-run phase, we typically work with API integrations that later grow into the final architecture.
When you should simply keep Salesforce
It would be unfair to tell only the pro-custom story. For a considerable share of the companies we speak to, Salesforce is not just reasonable but downright the right choice. A few clear signals.
You genuinely use deep Salesforce features
Salesforce Field Service for field service planning with dispatch, scheduling engines and a mobile workforce. CPQ for complex product configuration. Marketing Cloud Engagement for multi-channel journeys with large-scale segmentation. If these modules are indispensable to your operation, building a comparable system rarely outweighs the licence cost.
Genuine enterprise scale with international teams
With thousands of seats across multiple continents, regional compliance requirements and an established global pool of admin talent, Salesforce is often the pragmatic choice. Partner availability, and the fact that new employees already know the system, weighs more heavily than licence savings.
You have a well-negotiated enterprise contract
With an ELA (Enterprise License Agreement), a substantial discount per seat, bundled modules and fixed involvement in the roadmap, Salesforce can be surprisingly competitive. Renegotiating such a contract is almost always the first step before you consider custom.
Compliance file for customers or regulators
Some customers or regulators explicitly require a certified CRM platform with SOC 2 and ISO reporting. In heavily regulated sectors (financial services, life sciences, public procurement), keeping Salesforce is sometimes cheaper than pursuing equivalent certification for a custom build.
Further reading on the CRM decision
A CRM decision seldom stands alone. Here are the pages most often consulted by companies weighing this choice.
Building custom CRM software
Our main page on custom CRM describes the approach: discovery, MVP, phased rollout and ongoing development. It includes the stack choices (Postgres, TypeScript, Astro or Next.js for the UI).
Building a Salesforce integration
Even during or after a migration, a Salesforce integration is often still needed, for example to pull read-only data from the archive or to sync bidirectionally during a parallel run.
API versus integration platform
Our comparison of APIs and integration platforms helps you choose between MuleSoft, Workato, a lightweight iPaaS or direct API integrations, which is relevant if you are replacing a Salesforce stack with something new.
What custom software costs
For the broader TCO context, it is worth reading app and software costs. The principles (one-off build versus seat licences, ongoing development) also apply to a custom CRM.
Custom ERP system
Companies reviewing their CRM often review their ERP at the same time. Our page on custom ERP describes how to set up both systems so they work together.
Smart API integrations
For the broader integration questions (Outlook, telephony, marketing automation, ERP), our page on smart API integrations is the starting point. Many migrations begin by building a solid API layer before replacing the CRM.
Frequently asked questions: Salesforce versus a custom CRM
The questions that come up most often in our conversations with directors and IT managers weighing up the decision.
From how many users does custom development become cheaper?
There is no fixed number, but in our experience the business case usually becomes compelling from around 40–60 active seats. Below that, you run into the fact that one-off build costs cannot be spread out. The exception is smaller teams with a markedly unusual data model or heavy customisations in Salesforce, where Apex developer hours tip the total cost of ownership early.
How long does a migration from Salesforce to your own CRM take?
In our projects, an MVP covering 60–70 per cent of the functionality typically goes live in 4–7 months, running alongside Salesforce. A full cutover (including all teams, integrations and an archiving strategy) often takes 9–18 months, depending on complexity, change management and the number of AppExchange packages that need replacing. We strongly advise against big-bang migrations.
What do we do with our Apex code and Flows during migration?
Apex code is not carried over literally. The business rules within it are re-implemented in the stack of the custom CRM (often TypeScript or Python). More important than the code is the documentation: make sure a Salesforce architect, internal or from a partner, explains what each Apex class and each Flow does before developers begin. That discovery phase is not overhead; it is half of the migration work.
Can we use Salesforce alongside a custom CRM?
Yes, and in practice that is the normal picture during a parallel run. Some organisations keep Salesforce for one specific business unit (for example, international sales) and deploy a custom CRM for the other units. This does require good master data agreements: a single place where the account master lives, sync rules, and clear ownership of customer data.
How do we handle the AppExchange packages we need?
Assess each package: replace it with a SaaS equivalent that also runs standalone (for example DocuSign, Conga or a telephony integration), build it yourself, or set up standard API integrations. AppExchange packages that sit deep in Salesforce metadata (such as some CPQ extensions) often call for a wider review of the sales process, which is a sound moment to do so during a migration.
What does custom do worse than Salesforce?
A fair question. Three things: (1) matching the AppExchange ecosystem is practically impossible, (2) the availability of talent for your stack is smaller than the global Salesforce admin network, and (3) compliance certification requires extra investment in a custom build. For some organisations those drawbacks outweigh the total cost of ownership savings, and there is no shame in keeping Salesforce.
How do you guarantee we won't get stuck again in five years' time?
Three principles: (1) we build on open standards (Postgres, REST/GraphQL, OAuth, OpenAPI) so the system does not depend on proprietary tooling, (2) data export to common formats is always built in, not an afterthought, and (3) we hand over the source code and documentation so that, in theory, you could continue with a different development partner. That is the fundamental antidote to vendor lock-in.
What if we really need Einstein AI or Agentforce?
We build comparable AI functionality (lead scoring, opportunity insights, conversational agents) into custom CRMs using OpenAI, Azure OpenAI or Anthropic APIs. For most B2B CRM use cases, the quality of these models is now at least on a par with Einstein, and the cost structure is fundamentally different: you pay per API call, not per seat. For heavy vector search and Data Cloud-style analytics, we work with Postgres + pgvector, BigQuery or Snowflake.
What's the first step if we want to think about this seriously?
An honest TCO review of your current Salesforce setup, including licences, admin, consultancy, AppExchange and sandboxes, followed by a short discovery session in which we walk through your data model and the processes you use most. After that we can put together a fixed-price MVP proposal with a realistic business case. No sales pitch, no pressure: an honest comparison is either the starting point for a migration or confirmation that Salesforce is the right choice for you.
Want an honest TCO comparison?
Send us your current Salesforce setup (number of seats, edition, AppExchange packages, admin hours) and within a week we'll send you a substantiated 5-year TCO comparison tailored to your situation. No sales pitch, just the figures side by side.
Book a no-obligation introductory call