Custom CRM vs off-the-shelf CRM: which is right for a growing business?

Most requests for a custom CRM do not begin with a CRM problem. They begin with someone exporting two systems into a spreadsheet every Monday so that somebody else can make a decision on Tuesday. After a year of that, the request that reaches an engineering firm has already been converted into a solution: build us our own system.

The useful work happens before that. The same symptom is produced by at least four different underlying problems, and only one of them is solved by writing a CRM from scratch. Getting that diagnosis wrong is expensive in a specific way: a company spends two quarters building a system that reproduces the process that was causing the problem in the first place.

The signals that get read as a CRM problem

Four symptoms come up in almost every conversation. They are worth separating, because each one points somewhere different.

• A spreadsheet lives beside the CRM and is trusted more than the CRM. Usually a data problem: some system that matters is not writing into the CRM at all.
• A field named one thing contains something else — a notes field holding delivery dates, a status field encoding two states at once. Usually a configuration problem. The process outgrew the schema and nobody revised it.
• A report is rebuilt by hand on a schedule. Usually an integration or reporting problem. The data exists; it is in two places that do not join.
• Part of the team keeps a private list. Usually a process or adoption problem. The CRM is asking for work that does not pay the person entering it back.

None of these is evidence that the CRM is wrong. Three of the four are typically resolved without changing platform. The fourth — where the CRM genuinely cannot hold the shape of the business — is real, and it is the case this article is ultimately about. It is just less common than the volume of requests suggests.

Custom CRM is not one decision

The comparison is usually presented as two options. In practice a CRM decision lands in one of four places, and the two in the middle are where most growing businesses should be.

Framing it as configure or replace skips the two options that solve the majority of cases at a fraction of the cost, and — more importantly — leave you able to change your mind later.

The progression, in order of cost and reversibility

Each step below is cheaper, faster and easier to undo than the one after it. Work through them in order. Stop at the first one that resolves the business problem, and treat skipping a step as a decision that needs justifying rather than a shortcut.

1. 1

   Configure the CRM against the process you actually run

   Most CRMs are configured once, during onboarding, against the process as it was described rather than as it is performed. Re-model the objects, fields, stages and permissions against current reality. This is a week of work and it removes a surprising proportion of the complaints.

2. 2

   Fix the process before automating it

   Automating a process that nobody agrees on produces a faster disagreement. Where two teams have different definitions of a qualified lead or a closed job, settle that first. This step involves no technology and is the one most often skipped.

3. 3

   Integrate the systems that hold the missing data

   If the accounts system, the phone system, the support desk and the website forms do not write into the CRM, the CRM is a partial record and staff will keep their own. Most mainstream CRMs expose REST APIs and webhooks sufficient for this.

4. 4

   Automate the work that repeats without judgement

   Scheduled reports, record creation from inbound events, hand-offs between systems, notifications on state change. An orchestration layer handles this without changing the CRM, and it is straightforward to withdraw if it turns out to be wrong.

5. 5

   Build custom portals around the CRM, not instead of it

   When a workflow genuinely does not fit — a field engineer app, a customer-facing status portal, an approval flow with unusual rules — build that one thing and let it read and write to the CRM through its API. The CRM stays the record of truth.

6. 6

   Replace the CRM only when the evidence is already in

   By this point you have documented the process, mapped the integrations, and built against the CRM's own data model. That work is not wasted if you do build: it is precisely the specification a custom build needs, and it is the artefact most failed builds never had.

What each option costs to own

Comparing a subscription against a build quote compares the two smallest numbers in the decision. The costs that decide the outcome are the ones that recur.

Buying: the licence is rarely the largest line

Per-user pricing scales with headcount, which means the cost of the CRM grows with the thing you are trying to grow. Beyond that, the pattern worth planning for is the tier jump: one required capability — an integration, an approval rule, a permission model, an API quota — sits on a higher plan, and the whole user base moves up to reach it. Vendors publish their per-user tiers and change them; check the current figures directly with the vendor rather than relying on any comparison article, including this one.

Building: the build is rarely the largest line

A custom CRM is a system somebody has to keep running for as long as the business uses it. That means hosting, operating system and framework patching, dependency upgrades as libraries reach end of life, browser and integration changes forced by third parties, backup verification, and engineering availability when something breaks during business hours. None of these are optional and none of them stop.

There is no reliable public benchmark for the total cost of ownership of a custom CRM, because the variance between builds is larger than any average would be useful across. Figures circulating in comparison articles are generally unsourced. The productive exercise is to price the rows above against your own headcount growth and your own engineering capacity over five years, which produces a number you can defend.

What you take on when you build

This is the section most build-versus-buy comparisons omit, and it is the one that changes the answer most often.

When you buy, the vendor carries authentication, session management, access control, encryption at rest, patch cadence, penetration testing, breach notification, and whatever certification they hold. You inherit that as part of the subscription. When you build, every one of those becomes an internal obligation. It remains an obligation whether or not anyone is assigned to it.

This is manageable engineering work, not a reason on its own to avoid building. It is a budget line and a staffing decision that has to be made before the build, not discovered after go-live. In practice that means treating a CRM as what it is — a system holding customer personal data and commercial history — and building it against a published control set rather than against intuition. The OWASP Application Security Verification Standard is the usual reference for the application layer, and the NIST Cybersecurity Framework provides the language for deciding which controls the business owns.

Integration is usually the real problem

When a company says the CRM cannot do what they need, the requirement described is more often that the CRM cannot see what it needs. Those are different problems with very different price tags.

The telephony case

Sales and support operations running their own phone platform hit this consistently. The requirement is ordinary: an inbound call should open the matching customer record before the agent speaks, an agent should place a call without retyping the number, and the outcome of the call should end up on the record without anyone writing it there. Off-the-shelf CRMs handle this well for the telephony vendors they partner with, and poorly or not at all for a self-hosted platform.

Asterisk-based platforms such as FreePBX, along with 3CX and Vicidial, expose call events and management interfaces that make all three of those behaviours achievable against a CRM that is otherwise working fine. The work is integration work — event listener, number normalisation, a lookup against the CRM API, a write-back on call completion. It is measured in days, not quarters, and it does not require replacing anything.

Where an automation layer is the correct answer

A large share of what gets specified as custom CRM functionality is orchestration: when this happens in system A, create or update something in system B, on a schedule or on an event. A workflow automation platform such as n8n handles this without modifying either system, which matters for a reason that is easy to undervalue — if the logic turns out to be wrong, you change a workflow rather than redeploying an application. Reversibility is worth a great deal at the stage where the process is still being settled.

A decision matrix

Score each row honestly. The value is not the total; it is that the rows force the discussion into specifics.

A practical rule from repeated engagements: fewer than three marks in the building column and the answer is not to build yet. Exactly one mark, and the answer is almost certainly integration work that has been described as a CRM replacement.

An assessment you can run before calling anyone

This produces the information any competent engineering firm will ask for, and often resolves the question without needing one.

• List every spreadsheet that is maintained alongside the CRM, and for each one name the system the data should have come from.
• Count the systems holding customer data. If it is more than three, the problem is likely integration rather than platform.
• Take your two hardest workflows and walk them through the CRM you already have, as configured today. Note precisely where each one breaks.
• Check your current plan against the features you are working around. Some of them are usually already available and unconfigured.
• Export a sample of your data and read it. Migration difficulty is decided by data quality, and that work is required whichever direction you go.
• Identify who will own the system twelve months from now, by name. If nobody can be named, do not build.
• Establish what leaving looks like for both options — export formats and API limits on one side, code ownership and documentation on the other.

A representative scenario

The following is a composite of situations we see repeatedly rather than a single engagement, and no client detail is included.

A services company of roughly sixty staff approaches us to build a custom CRM. The stated reason is that their CRM cannot produce an accurate view of a customer. The review finds three systems each holding a version of the customer: the CRM, the accounts package, and the phone platform, which had been deployed later and never connected to either. Staff had responded rationally by maintaining a spreadsheet that reconciled all three, and management was making decisions from the spreadsheet.

None of that is a CRM defect. The first phase connected the phone platform to the CRM so calls resolved to records and outcomes were written back, and synchronised the customer and invoice records between the accounts package and the CRM on a schedule. The spreadsheet became redundant within a fortnight. A second phase built one custom portal, for a scheduling workflow the CRM genuinely could not model, reading and writing through the CRM API.

The CRM was kept. The outcome was a fraction of the cost of the build originally requested, and the company retained the option of replacing the platform later — better informed, with the process documented and the integration layer already in place.

Frequently asked questions

Conclusion

The question is rarely custom or off-the-shelf. It is which step of the progression the business is actually on, and whether the steps before it have been done properly. Companies that work through configuration, process, integration and automation in order either find that the problem is solved before a build is needed, or arrive at the build with a documented process, a working integration layer and a clear specification. Both outcomes are good ones.

Companies that skip to the build tend to arrive at the same place eventually, having paid for it twice. If you are weighing this decision, run the assessment above first. It costs a week and it is the difference between a technology decision and an expensive guess.