ZIONN
Modernization2 min read

Custom CRM or off-the-shelf: the same test, applied to sales

Build versus buy has a sales-specific version. If your pipeline stages or approval flow are not what the CRM assumes, off-the-shelf gets expensive fast.

ZIONN EngineeringSoftware engineering team

The general build versus buy test asks whether a capability is a commodity or the thing you compete on. Applied to a CRM, most of it is commodity: contact records, activity logging, email sync, a pipeline board. Buy that, every time.

The part worth asking twice about is narrower: the exact shape of how your team sells, when that shape does not match what any off-the-shelf CRM assumes.

Where "customize the platform" quietly becomes "build"

Every mainstream CRM lets an administrator add custom fields, custom stages, and workflow rules through its own configuration UI. That covers most companies. It stops covering you at a specific point: when the customization needed is not a field or a rule, but a different object model entirely.

Buy and configureThe common case, for most teamsBuy, then build the edgeA thin custom layer over a standard CRMBuy and adapt the processCheaper than fighting the platformBuildMulti-entity deals, usage-based pricing, regulated approval chainsSALES PROCESS IS THE DIFFERENTIATORSTANDARD SALES PROCESSPLATFORM MODELS IT NATIVELYPLATFORM DOES NOT MODEL IT

The bottom-right quadrant is real and specific: multi-party deals where three companies close one contract together, usage-based pricing that needs to recompute a forecast on live consumption data, or an approval chain a regulator requires to be enforced, not just documented. A generic CRM can be bent toward these with enough workflow rules, and the bending is where the maintenance cost lives.

The configuration trap looks like a bargain

A platform configured across hundreds of fields and workflow rules by an administrator is a codebase with no version control, no tests, and no code review, and the person who understands why a rule exists usually leaves before the documentation does. This is the same trap the general build-versus-buy analysis describes for any bought platform: the license cost is small, and the accumulated configuration is where the real cost hides.

The honest question is not "can the platform be configured to do this," because the answer is almost always yes. It is "what does it cost, in ongoing maintenance and in the next administrator's onboarding time, to keep that configuration correct." Past a certain point, a thin custom application sitting beside a standard CRM, talking to it over a real API, costs less to maintain than the workflow-rule tangle it replaces.

Not sure which side of that line your team is on? Our assessments include the general build-or-buy test, and it applies here directly.

We help teams make this call as part of our CRM & Revenue Operations practice, using the same engineering judgment we apply to any build-or-buy decision, not a sales pitch for either side.

Check your own case

Where does your team stand on this?

The article describes the pattern. These take your answers and tell you which part applies to you — no signup to see the result.

Related services

  • Custom software development

    Platforms and internal tools built for how your business actually works.

    Learn more
  • CRM & Revenue Operations

    Migration, implementation, custom development, and training for the CRM your sales team actually uses.

    Learn more

Keep reading

All articles