Should you build a custom CRM?

The short test

Three signals genuinely predict that a custom CRM will pay for itself. If two or more apply to you, it is worth a conversation. If none do, stay where you are.

Signal 1: your records are not contacts and companies

Every off-the-shelf CRM is built around a person who works at an organisation, and a deal with a value and a close date. That model fits most sales teams.

It does not fit a business whose real unit is a school, a vessel, a property, a venue, a supplier or a building. You can force those into a “company” record, but you end up with twelve custom fields, a naming convention nobody follows, and a spreadsheet beside the CRM holding everything that would not fit.

The spreadsheet beside the CRM is the tell. It is there because the CRM cannot hold what actually matters to you.

Signal 2: keeping the data current is somebody’s job

If a human being is paid to check whether records are still accurate, you have a data problem, not a CRM problem — and most off-the-shelf CRMs offer nothing here beyond flagging a bounce.

This was the central issue for Yeppe: schools change staff constantly, so an email would bounce, the contact would go on a list, and an outsourced team would work through that list a few times a year, checking websites and directories by hand.

A custom system can go further, because it knows what your records are. It can pull from the official source, derive email addresses from each organisation’s own pattern, verify them before anyone sends, and feed bounces back into a fix rather than a to-do list.

Signal 3: one process spans three products

You use a CRM for the pipeline, a separate tool for proposals, a spreadsheet for forecasting and your accounting package for invoices — and the same information is typed into all four.

Each individual tool is fine. The gaps between them are where the cost is: the retyping, the version that is out of date, the reconciliation at month end.

When you should absolutely not build one

Your process is standard. If you sell a product to a company via a pipeline with recognisable stages, HubSpot does this extremely well and has a decade of polish you cannot replicate.

You want a custom CRM to fix adoption. If the team is not using the current CRM, find out why first. Building a new one they also will not use is an expensive way to discover the problem was training, process or incentives.

You are under ten people with a simple pipeline. The overhead of running your own system is not worth it yet. Revisit when the spreadsheet appears.

You cannot name the specific thing the current tool cannot do. “It’s clunky” is not a specification, and it will not survive contact with a build.

What it realistically involves

A custom CRM is not one project. It is a first version plus a long tail.

The first version should be your real contact data, imported and deduplicated, and the single view your team opens every morning. If that view is being used daily within a few weeks, everything else follows naturally. If it is not, you have learned something important and cheaply.

The long tail matters because a CRM is never finished — the business keeps changing, and the system has to change with it. Factor in ongoing work from the start rather than treating it as a failure of the original build.

The ownership question

With a custom system, you own the code, the data and the accounts. No per-seat pricing, no vendor deciding to deprecate the feature you depend on, no export process when you want to leave.

That matters more to some businesses than others. If your contact data is a genuine competitive asset — because you have invested in making it more accurate than anyone else’s — owning it outright is part of the point.

Still not sure?

The honest way to decide is to cost the status quo. Add up the subscriptions you would replace, plus the hours spent on manual maintenance and retyping, and annualise it. That number is what you are already paying for the current arrangement, and it is usually the one that settles the argument.