Custom CRM vs Salesforce: how to actually decide

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 use Salesforce?

How to decide:

Your process is leads, opportunities, stages and a close date. Buy. That is precisely the model Salesforce ships with. Building it yourself is paying to recreate a solved problem.

You need something working in weeks and the process is ordinary. Buy. Off-the-shelf is operational in days. A custom build is months of discovery before anyone logs in.

The standard objects fit but the fields, layouts and automations do not. Configure. This is what the platform is for. Bring in a good admin or partner before you consider a rebuild.

One record must exist in several states at once — several lenders, several carriers, several courts. Build. A single stage field cannot express it, and every workaround makes the pipeline less true.

The relationship continues for years after the deal closes and that period is where your money is. Build. Closed-won is the end of the standard model and the middle of your actual business.

You are paying per seat for people who only need to see one screen. Build. Per-seat licensing punishes exactly the operations, field and back-office staff who most need visibility.

Your admin cost has quietly become a full-time role plus consultants. Build. At that point you are already paying for custom software. You are just renting the platform underneath it too.

What drives the cost:

Licensing compounds with headcount, a build does not. Per-seat pricing scales with every person you add. A build has a large one-off cost and then hosting. The crossover point depends on seat count and years, and you should model it over five years rather than one — that is the horizon these systems actually live on.

Implementation is usually the bigger number. For most mid-size deployments the configuration, data migration and integration work costs more than the first year of licences. This is true whichever route you take, which is why it is a poor tiebreaker.

Customisation on a platform is not free either. Custom objects, flows and Apex are development work with a platform's constraints on top. Firms with genuinely unusual processes often find platform customisation reaches custom-build cost while keeping the platform limits.

The cost nobody quotes is re-keying. Hours per week spent moving the same data between the CRM and the thing the CRM cannot model. It never appears in a comparison and it is frequently the largest line.

What people get wrong:

Deciding on price rather than fit. A cheap system that cannot express your core object costs more within two years than an expensive one that can, because the difference is paid in staff time forever.

Assuming custom means replacing everything. The best outcome is usually narrow: keep the accounting, keep the platform your team already adopted, and build only the object that does not exist. Wholesale replacement is rarely the right shape.

Believing the demo. Every platform demos beautifully against a generic process. Take your single most awkward real record into the demo and ask them to model it. The answer is the whole decision.

Ignoring who maintains it. A custom build with no one to maintain it becomes legacy in eighteen months. If nobody owns it internally, that is a genuine argument for buying.

Is Salesforce too expensive for a small business?

Price is rarely the real problem; fit is. A ten-person firm whose process matches the standard model gets good value. A ten-person firm forcing a multi-party workflow into opportunities pays twice — once in licences and again in the staff time spent working around it.

How long does a custom CRM take to build?

A focused build covering one or two objects that do not exist off the shelf is typically weeks. A full replacement of an established CRM is months and carries migration risk. The scope you choose matters far more than the technology.

Can we start on Salesforce and move later?

Yes, and it is often the sensible sequence. Buy to get running, learn what genuinely does not fit, then build only that. The mistake is committing to a rebuild before you can name the specific object the platform cannot express.

Do we own the code if you build it?

You should, unconditionally, and you should confirm that in writing with any firm you hire. A custom system you do not own combines the cost of building with the lock-in of buying.

What if we already customised Salesforce heavily?

Then the question changes from build-or-buy to whether the platform is still adding value over what you have built on top of it. Count your admin and consulting spend for the last year first; that number usually answers it.

Last reviewed 22 August 2026