Should You Build Your Own CRM? Run the Build-or-Buy Test on Your Sales Process

The build-or-buy test asks one question of any capability: is this a commodity, or is it part of how you win? Applied to a CRM, the answer is almost always "buy" for the product as a whole and occasionally "build" for one narrow piece of it. The work is finding out whether you have such a piece, and noticing when a heavily configured platform has already turned into a build without anyone deciding it should.

Most of a CRM is commodity, and you should treat it that way

Contact and company records. Email and calendar sync. Activity logging. Task reminders. A pipeline view with draggable stages. Role-based permissions. Standard reports. A mobile app.

No company wins deals because its contact database is better than a competitor's. These features are solved problems, maintained by vendors with far more engineers than you will ever assign to them, and improved every quarter at no extra effort on your side. Rebuilding them means paying for parity and then paying again to keep up.

So the default is clear. If someone proposes replacing a mainstream CRM with a fully custom one, the burden of proof is on the proposal.

The interesting question is narrower. It concerns the shape of the sale itself: what a deal is, who is party to it, how it is priced, and what has to be true before it can close. Off-the-shelf platforms assume a particular shape. When yours is different, that difference is where the decision lives.

The model every platform assumes

Under the configuration screens, mainstream CRMs share a core data model. A company has contacts. A deal belongs to one company and one owner. A deal moves through a linear sequence of stages. It has one amount and one expected close date. When it closes, it is won or lost.

That model fits a very large share of B2B selling, which is why it became the standard. It fits poorly when the real structure of your business contradicts one of its assumptions. Some examples, framed as patterns and not as any particular company:

• Multi-party deals. A contract closes only when a manufacturer, a distributor and an installer all commit. There is no single "customer", and each party has its own stage.
• Usage-based or consumption pricing. The deal has no fixed amount. Revenue depends on metered usage after signing, and the sales team is paid on something other than the booking.
• Channel and partner sales. A deal is registered by a partner, worked jointly, and split by rules that depend on who sourced it.
• Non-linear pipelines. Regulated or project-based sales where steps run in parallel, loop back, or depend on external approvals with their own clocks.
• Quotes with heavy logic. Pricing depends on configuration rules, inventory, freight and contract history held in an ERP.

In each case the platform can store something. The question is whether what it stores still means what the business needs it to mean.

Four options, not two

"Custom or off-the-shelf" is a false binary. In practice there is a spectrum.

Most conversations that begin with "we need a custom CRM" end at the first row done properly. The team was not short of software. It was short of a clear process and a disciplined configuration.

A meaningful minority end at the third row, and that row is underused. The platform stays the system of record for accounts, contacts and activity. The part that does not fit (the multi-party deal engine, the usage-based pricing calculator, the partner split logic) lives in a small custom service with a real data model, real tests and its own release process. Reps still work in the CRM. The custom service does the part the CRM was never designed to do.

The fourth row is rare and should be. It is defensible when the selling workflow is itself what the company offers, or when data residency, security or regulatory constraints cannot be met by any vendor.

The moment configuration turns into an unplanned build

Adding fields, stages and workflow rules through an admin screen is something all of these products support. That is configuration, and it is what the product is for. The line is crossed gradually, and you can tell it has been crossed by a few signs:

• A standard object is being used to represent something else. Deals stand in for projects, contacts stand in for partner companies, and a text field holds structured data separated by semicolons.
• Automations exist mainly to work around the data model: rules that copy values between records to simulate a relationship the platform does not support.
• A meaningful amount of logic lives in the platform's proprietary scripting language, written by a contractor who has moved on.
• Platform updates break things, and you learn about it from the sales team.
• One administrator is the only person who understands how it works, and their vacation is a business risk.
• A request that sounds small ("split commission across two reps") gets an estimate measured in weeks.

At that point you own a custom application. It simply happens to be written in the least maintainable medium available.

Cheap changes, expensive system

Each individual change through the admin interface is cheap. No developer, no deployment, done by lunch. That is exactly what makes the accumulated result expensive.

Several hundred fields and rules amount to a codebase. Compare how that codebase is usually managed with how you would manage ordinary software:

Many platforms do offer sandboxes, deployment tooling and change tracking, and mature teams use them. The point is that these disciplines are optional on a platform and tend to be skipped, because the tool makes it so easy to change production directly.

Asking whether the product is capable of the behavior you want gets you nowhere, because with enough rules the reply is nearly always yes. A more useful thing to ask is what it costs to keep that configuration correct for five years: through vendor releases, staff turnover, a pricing change, an acquisition, and a new product line that sells differently.

Run the test on your own pipeline

Work through these in order. Write the answers down, because the act of writing usually settles the matter.

1. Describe one real deal from first contact to cash. Not the ideal one. A recent, typical one, including the awkward parts.
2. Mark every point where the description contradicts the standard model. More than one customer? No fixed amount? Stages in parallel? Approval that depends on data outside the CRM?
3. For each contradiction, ask whether it is a source of advantage or an accident of history. A pricing model customers choose you for is an advantage. An approval chain that exists because of a reorganization three years ago is an accident. Fix accidents by changing the process, not by building software around them.
4. For the contradictions that survive, check the platform's intended extension points. Custom objects and documented APIs are intended. Repurposing standard objects is not.
5. Estimate the rule count. If supporting the requirement needs dozens of interdependent rules, treat it as software and price it as software.
6. Compare five-year costs, not launch costs. For the platform path: licenses at your projected headcount, add-ons, administrator time, consultant fees for changes, and the cost of each change taking longer than the last. For the custom path: build, hosting, maintenance, and an engineer who stays responsible for it.
7. Ask what leaving would cost. How would you get your data and logic out of each option?

If step 3 leaves you with nothing, buy and configure well. If it leaves one or two real items, look hard at a custom module alongside the platform. If it leaves most of the process, you may be one of the few cases for a full build.

What goes wrong on the build side

Fairness requires the other list. Teams that build their own CRM tend to underestimate the commodity layer. Email sync alone, done reliably across providers, is a substantial project. So are permissions, mobile access, duplicate handling, audit trails and reporting that non-technical managers can change themselves.

A custom system also needs an owner for as long as it runs. Without a budget line for maintenance, it ages into the same unmaintainable state as the over-configured platform, with the added problem that no vendor is coming to fix it.

That is the strongest argument for the hybrid: buy the commodity, own the difference, and keep the boundary between them explicit.

Which rule do you keep fighting your CRM over?

If there is one requirement your platform has never handled cleanly, that requirement is where the decision sits. Bring it to Trivo along with a description of a real deal, and we will give you a plain answer: better setup of the platform you already pay for, a small custom service beside it, or a real case for building.