Build, buy or configure

Most build-or-buy advice is written by whoever profits from the answer. These guides give the honest call for each situation, including the many where buying an off-the-shelf product is obviously right.

Should we build a custom CRM or use Salesforce? Buy Salesforce if your process is a recognisable sales process — leads, opportunities, stages, a close. Build custom if the thing you track is not an opportunity at all: a file submitted to several parties at once, a matter with statutory deadlines, a unit with a service history, a placement with a margin. The deciding question is not company size or budget. It is whether your core object exists in the standard model.

Should we build a custom CRM or stay on HubSpot? Stay on HubSpot if your problem is attracting and converting leads. Build alongside it if your problem starts after the deal is won — fulfilment, documents, compliance, recurring service, anything with a state that is not a pipeline stage. HubSpot is a marketing and sales platform that also stores contacts. Most firms who outgrow it have not outgrown the marketing half at all.

Should we buy software or have it built? Buy when the problem is common, the category is mature, and your version of it is ordinary — accounting, payroll, email, e-signature, helpdesk. Build when the process is the thing customers actually pay you for, when no product models your core object, or when the category tools all assume a business shaped differently from yours. Everything else is configuration, which is neither and is usually the cheapest correct answer.

How much does custom software cost? Any firm quoting a figure before understanding your scope is guessing. What genuinely moves the number is scope, integration count, data migration quality, compliance requirements, and whether you need a prototype or a production system. The most useful thing you can do is get two firms to quote the same narrowly-defined first deliverable — comparable quotes tell you far more than a range ever will.

Is it time to replace our CRM? Replace it when people are keeping the real information somewhere else — a spreadsheet, a notebook, a group chat — because the system cannot hold it. That is the one signal that reliably means the tool is wrong. Poor adoption, messy data and unhappy users are usually process and ownership problems, and they will follow you to the next CRM.

Should we configure what we have, buy something new, or build? Configuration is the answer far more often than either vendor will tell you, because nobody makes money recommending it. Try it first, deliberately and with a deadline. Buy when the function is a commodity. Build only when you can name the specific object or workflow that no product models — and then build only that, not everything around it.