Of all the custom builds people ask me for, the CRM is the one where I most often end up arguing against my own invoice. Not because custom CRMs never make sense. Because the request almost always comes from the wrong diagnosis: the team hates their current CRM, concludes the category is the problem, and reaches for "we'll build our own" the way you reach for "we should move to the countryside" after a bad commute.
Let me lay out the actual bar, and the trap on the other side of it.
Why the CRM is the most dangerous build
A CRM looks like a table of contacts with some stages. That is the visible tenth of the iceberg. The submerged part: permissions and territories, deduplication, activity capture from email and calendar, pipeline math that finance trusts, integrations with billing and support and marketing, mobile access, audit trails, and imports from the old system with ten years of dirty data. Every mainstream CRM has spent years grinding through that list. Your custom build starts the grind at zero, and the grind is the product.
This is the specific trap: the demo of a custom CRM is achievable in weeks and looks glorious. The gap between that demo and a tool your whole company can live in is the expensive part, it arrives after the money is spent, and it never stops arriving. You have not bought a tool. You have founded an unprofitable software company with one customer.
The bar: all three, no exceptions
I take CRM-shaped builds only when all three hold:
- The process is the advantage. Your deal flow, intake model, or operations genuinely differ from how the market works, and that difference is why you win. A specialty broker with a matching workflow no pipeline tool can express: maybe. A company that sells B2B with stages and follow-ups: no, that is every CRM's home turf.
- Extension has actually been tried. Mainstream CRMs are platforms; custom objects, automations, and API integrations solve most "it doesn't fit us" complaints at one-tenth the cost of a build. If nobody has seriously tried to extend, the build request is an emotion with a budget.
- There is an owner and a maintenance budget, in writing. Forever, not for launch quarter. A CRM is operationally critical; when it breaks, sales stops. Orphaned custom CRMs do not degrade gracefully, they hold companies hostage.
What usually actually fixes it
The complaints behind "we need a custom CRM" cluster into three, and each has a cheaper cure:
- "It doesn't match our process." Configuration debt. The CRM was set up in a hurry years ago and never revisited. A few days of honest reconfiguration beats a rebuild.
- "Nobody uses it properly." An adoption and incentive problem. Software does not fix what management tolerates; a custom tool will be ignored with equal enthusiasm.
- "Our data in it is garbage." A hygiene and integration problem, solvable with dedup, validation rules, and wiring the CRM to the systems where truth lives. Garbage migrates happily into custom software.
Notice none of these is a build. The build fantasy is attractive precisely because it promises to skip the boring fixes. It does not; it defers them into a more expensive container.
When it genuinely is a build
If the three-condition bar holds, the winning move is still not "rebuild Salesforce." It is the narrow tool: keep a mainstream CRM (or a lightweight one) as the system of record, and build the specific workflow that does not fit as a small application beside it, integrated through the API. The custom piece stays small enough to maintain, the commodity piece stays somebody else's maintenance problem, and you avoid becoming a vendor.
That shape, a bounded custom tool next to bought infrastructure, is the same conclusion as the dashboard decision, and it is not a coincidence. It is what build-vs-buy converges to almost every time someone does the maintenance math honestly.
The one-page test before you spend anything
Write your sales process on one page, as it really happens. Hand it to someone who knows the mainstream CRMs well and ask one question: which parts of this can a standard platform not model? If the answer is "none, but ours is configured badly," you have a configuration project. If the answer names a real structural gap, scope a build for that gap alone and nothing else.
I do these assessments as paid short engagements precisely because my incentive needs to be the right answer, not the big build. Half the time the deliverable is a reconfiguration list and a closed wallet. The other half, the build that follows is small, owned, and actually worth it.