Custom CRM or off-the-shelf? Decide on the object model.

Feature comparisons are the wrong tool for this decision, because every mature CRM has every feature. The question that actually predicts whether a platform will work for you is whether its object model matches how your business really sells.

A standard CRM assumes a shape: leads become contacts, contacts belong to accounts, opportunities attach to accounts and move through stages toward a close date and a value. If your business fits that shape, off-the-shelf will serve you well for years and you should not build anything.

It stops fitting in specific, recognisable ways. When the thing you sell is quoted per line item against a technical specification, the opportunity is not the unit of work - the quotation revision is. When a deal is one project with many parties who each need a different view, an account cannot represent the relationship. When the pipeline is driven by an external event you do not control - a tender cycle, a licence renewal, a contract expiry - stages measured against a forecast close date describe nothing useful.

Those are object-model mismatches, and no amount of custom fields resolves them. Custom fields bolted onto the wrong object produce a CRM everybody works around, which is the most expensive outcome available: you pay for the licences and keep the spreadsheet.

This is rarely a binary choice, and framing it as one leads to over-building. There are three positions, and the middle one is where most companies should land.

The build cost is the visible number and usually not the important one. A custom CRM is a system you now own for as long as you use it, and ownership carries recurring obligations that a licence fee was quietly covering.

Security patching of dependencies, on a schedule rather than on incident. Backups that are tested by restoring them, not merely configured. Access control that stays correct as people join, change role, and leave. Uptime monitoring and someone who responds to it. Integrations that break when the other side ships a new API version. Onboarding for new staff into a tool with no public documentation or training market.

None of these is a reason not to build. They are a reason to price the decision over three years rather than on the build quote, and to have a support arrangement in place from day one rather than discovering the need after the first incident.

Some capabilities are consistently weak in general-purpose CRMs and consistently valuable, which makes them good candidates to build alongside a platform you keep.

Quoting against a real product or service catalogue, with revisions, approval thresholds, and a document that matches your commercial terms. Client portals, where the customer sees their own status without anyone emailing an update. Operational dashboards that combine CRM data with delivery, finance, or inventory data the CRM does not hold. Automated follow-up that is driven by the actual state of a deal rather than a fixed sequence, and that drafts a message a human approves before it sends.

Each of these integrates over the CRM's API and leaves it as the system of record. That is the pattern to prefer: one place where a customer record lives, purpose-built surfaces around it.

Whichever direction you go, moving from what you have now is where projects come apart - and the risk is concentrated in data, not software.

Spreadsheet history is inconsistent in ways nobody notices until it is loaded: the same company spelled four ways, dates in two formats, stages that changed meaning eighteen months ago, records owned by people who have left. Deduplication and normalisation should be treated as a distinct workstream with someone from the business owning the decisions, because most of them are business calls rather than technical ones.

Run the old and new systems in parallel for a defined period rather than switching on a date. Migrate in waves, verify record counts and totals after each wave, and keep an exportable archive of the original data. Any system worth adopting must let you get your data back out in a usable form - confirm that before you migrate into it, not after.

Ask five questions. Can our process adapt to the platform's model without the team maintaining a parallel spreadsheet? Is the thing we do differently a workflow, or just a preference? Does the platform's API expose what we would need to integrate? Can we live with where it stores our data? And are we prepared to own maintenance for as long as we use it?

Four or five yes answers to the first four questions means configure and integrate. A no on the object-model question, plus a yes on the maintenance question, is where a custom build earns its place.