What is a custom CRM, and when do you actually need one

A custom CRM is one where the core can change - what an object is, how a stage behaves, what happens between two steps. That is different from a configurable product, where you can only decorate the edges. It is also different from a bespoke build, where you pay to recreate things every CRM already has.

The term gets used for all three, which is why people assume "custom" means "expensive and slow". Usually it means the middle one, and the middle one is neither.

The three things people mean by custom CRM

1. A configurable product. HubSpot, Pipedrive, Zoho and the rest all offer custom fields, custom pipeline stages, and automation between existing objects. Vendors call this customisation. It is configuration - real and useful, but bounded by the shape they designed.

2. A build from scratch. A development team builds a CRM for you, starting at nothing. You get exactly what you specify. You also pay to build contact management, deal tracking, permissions, email sync, search and reporting - things that exist in every CRM on the market and are not where your business is different.

3. A changeable core. A working CRM with the standard things already in it, where the parts specific to your business get built into the product rather than worked around. The foundation is shared; the shape is yours.

This post is mostly about the third, because the first two are well understood and the third is the one people do not know exists.

Configuration versus customisation

The distinction sounds academic until it costs you a year.

Configuration answers: can I store this, and can I automate between the things that exist? Custom fields, custom stages, workflow rules, a calculated property. All of it works within the vendor's model of what a deal is and what happens to one.

Customisation answers: can the model itself be different?

Concretely - a company where a deal has to be approved by two people in sequence, and the second approver depends on the value. No custom field represents that. It is not a property of a deal, it is a behaviour, and behaviours belong to the product. You can approximate it with statuses and reminders, and everyone will know it is an approximation.

That is the line. Below it, configuration is fine and cheaper. Above it, no amount of configuration reaches.

When do you actually need one?

Not at a headcount. There is no number of users at which you graduate to custom.

The trigger is a workflow the product cannot represent. Which shows up in a spreadsheet beside the CRM - the real process living outside the system of record, because the system of record cannot hold it.

Some specific shapes that produce this:

• Approval chains that depend on value, region or product
• Products configured per customer, where a deal is not one line item
• A handover between sales and delivery with its own steps and owners
• Pricing logic that is not a discount percentage
• An industry object that is not a contact, company or deal - a vessel, a property, a case, a shipment
• Compliance steps that must be recorded in a specific order

If none of those describe you, you almost certainly do not need a custom CRM, and anyone telling you otherwise is selling.

When you should not

Three cases where we would point you elsewhere.

Your process is standard. Most are. Standard processes exist because they work. A fixed product will give you more features on day one than any custom build, for less money.

The process is the problem. Sometimes nothing fits because the workflow grew by accident and nobody has questioned it in years. Building that into software makes it permanent and expensive. Occasionally the right move is to fix the process and find the standard tool was fine.

You need a different category of product. Field service management, a support desk, a full ERP. A CRM is the wrong foundation for those, customisable or not.

What it costs, and why the middle option is cheap

A build from scratch is tens of thousands, because you are paying for everything - including the 80% that is identical to every other CRM. We have broken the three paths down properly in build, buy, or build on top.

A changeable core is not, because that 80% already exists. Ours is priced per engagement rather than per seat, quoted as a fixed price after one scoping call covering migration, the first custom build and training.

The economics work because customisation is additive rather than foundational. You are paying for the part that is actually about your business, and nothing else.

The question that sorts vendors quickly

Ask any CRM vendor: what happens when we need something the product does not do?

"Submit a feature request" means wait, possibly forever. "Upgrade to Enterprise" means pay more for a bundle around your one feature. "Use the API" means hire a developer and maintain an integration. "We build it, here is the cost and the timeline" is a different kind of answer.

None of them is wrong. But the answer tells you which product you are actually buying, and it is much better to know before the spreadsheet appears than after.