Almost everybody who wants a custom CRM should configure an existing one instead. This article is about the minority for whom that is genuinely not true.
The four situations where building is justified
1. The record is not a contact
Standard CRM assumes a company, contacts within it, and opportunities. Some businesses do not work that way.
A marine services firm tracks vessels, and the owner, the operator and the technical manager may all be different organisations. A property maintenance business tracks buildings, with landlords, agents and tenants attached. A plant hire company tracks machines.
When the thing you actually manage is not a company or a person, standard products force a translation that everyone finds awkward — and the awkwardness never goes away.
2. The CRM and operations are the same thing
In many service businesses, an enquiry becomes a survey, becomes a quote, becomes a job, becomes a schedule, becomes an invoice, becomes a maintenance record.
Splitting that across a CRM and a separate job system means data crossing a boundary at every stage and reconciliation forever. A single system covering the whole chain can be worth building, and it is a bigger project than a CRM.
3. Pricing or configuration rules are the business
If quoting involves rules that take a person twenty minutes and a spreadsheet, a system that encodes those rules delivers a measurable return — see quoting and invoicing systems.
Standard CRMs handle line items and discounts. They do not handle "this specification with that option is not permitted, and the third one changes the lead time".
4. Regulatory or contractual requirements no product meets
Retention rules, evidence chains, audit requirements, or a customer contractually requiring data be held in a specific way. If a product cannot satisfy it, configuration will not help.
The reasons that are not sufficient
"Nothing does exactly what we want." True of everyone. The question is what the gap costs annually, not whether it exists.
"Subscription fees add up." They do. So does maintaining custom software. Compare over five years including hosting, development and the cost of someone else taking it over.
"We want it to work the way we work." Sometimes the way you work is habit rather than advantage. It is worth being honest about which.
What a custom CRM should contain
Less than you think. The first release should cover:
- Whatever the central record is — customer, vessel, property, site
- People attached to it, with their roles
- A history of contact, populated automatically from email where possible
- Open opportunities or jobs, with a stage and a dated next action
- Documents attached where they belong
- The one report the business genuinely runs
Resist everything else until it has been in daily use for a quarter. The requests that arrive after real use are informed; the ones written in advance are guesses.
What it should connect to
A custom CRM that does not exchange data with your other systems recreates the isolation you were escaping. Scope these from the start:
Email, so correspondence records itself. Without this, adoption will be poor regardless of how good the rest is.
Accounting, so quotes become invoices and payment status is visible without opening another system.
Calendars, so appointments appear in the tools people already use.
Your website, so enquiries arrive as records rather than emails somebody retypes.
The integration work is usually larger than the CRM itself. Businesses budget for the screens and are surprised by the plumbing.
The ongoing cost
Custom software is a commitment rather than a purchase. Budget annually for hosting and backups, security updates and dependency maintenance, support, and continued development — because people will ask.
A reasonable planning figure is a meaningful percentage of the build cost every year. A business that stops paying this ends up with a system that works but slowly falls behind the way the company operates, which is how custom systems become the legacy system somebody has to migrate off later. See moving off a legacy system.
Reducing the risk
Start with a discovery. The exceptions and the data problems are the project — see what a technical discovery involves.
Release something small and use it. Three months of real use is worth more than a year of specification.
Use conventional technology. Whatever the widest pool of developers knows.
Own the code, the hosting and the data. Written into the agreement — see who owns your code.
Insist on documentation and automated tests. They are what makes it possible for somebody else to take over safely, and they are the first thing dropped when a budget is tight.
The honest alternative worth testing first
Use a capable existing CRM for a year, accepting its limitations, and build only the one piece that genuinely does not fit — connected to it.
You will learn far more about your real requirements from a year of use than from any specification, and a later build informed by that is cheaper and much more likely to be right.
Our CRM team builds custom systems for UK businesses and regularly advises against it. Discuss your requirements and we will tell you which side you are on.
