Custom CRM vs off-the-shelf: when custom actually wins.
We build custom software, so treat our opinion accordingly — but we turn down projects where a platform is the better answer, because a badly-fitted custom build is worse than a well-fitted off-the-shelf one.
What off-the-shelf is genuinely good at
- Speed. You can be running this week. No build can compete with that.
- Ecosystem. Thousands of pre-built integrations and a large pool of people who already know the tool.
- Shared R&D. Costs are spread across thousands of customers, so the platform ships features you would never fund alone.
- Low commitment. If it does not work out, you cancel. That optionality has real value early on.
If your process is standard, that list is decisive. Use the platform.
Where it breaks down
Your process becomes the software's process. Platforms encode assumptions about how work should flow. Where your operation differs — and if you are good at something, it differs — you either abandon your approach or build workarounds around the tool.
You pay for the whole product. Per-seat pricing charges for capability, not usage. Teams routinely pay enterprise rates while touching a fraction of the features.
Costs scale with headcount, not value. Hiring five people increases your software bill by five seats regardless of whether those people generate five seats' worth of value from it.
You inherit someone else's roadmap. Features get deprecated, pricing changes, direction shifts. You have no say and no recourse.
An honest decision framework
Ask these four questions, in order:
- Is my process genuinely different, or just familiar? Be ruthless. Most differences are habit, not advantage. If yours is habit, adapt to the platform.
- What is the workaround cost? Count the hours per week spent on re-keying, shadow spreadsheets and reconciliation. Multiply by a year. That is the real comparison figure — not the subscription.
- How long will I run this system? Custom's economics improve over time. Two years favours a platform; seven strongly favours ownership.
- Is the constraint costing me growth? If you cannot take on a client type or open a location because the software cannot express it, the software is now a business problem.
The middle path most people miss
It is rarely all-or-nothing. The strongest setups we build keep the platforms that genuinely earn their place — accounting is a common one — and build custom only where the business is actually differentiated, with clean integration between them. That is often cheaper than either extreme and produces a system that fits without rebuilding everything.
Common questions
Not universally. Salesforce is better when your process is standard, you need speed to deploy, and you want a large ecosystem of ready-made add-ons. Custom is better when your process is your competitive advantage, when you are paying for capability you never use, or when platform constraints have started forcing workarounds.
Yes, and it is often the sensible path. Running a platform first teaches you exactly which parts of your process are genuinely non-standard — which makes the eventual custom build cheaper and better scoped. Just keep your data exportable.
Scope drift and dependency on the firm that built it. Both are manageable: insist on a written scope before development, and insist on full code ownership plus documentation at handover.
Not sure which side you're on?
Tell us how your operation runs. If a platform fits you better, that is what we will tell you.