Buy, configure, connect, or build a CRM data-quality capability

Facing a broken dedupe process, runaway enrichment spend, and no sequence governance, the instinct is to build a custom tool for all three. That instinct is usually premature. A credible data-quality program rules out buying, configuring what you already have, and connecting an integration before it reaches for a custom build, and it builds only the specific capability none of the other three paths can meet.

Four paths, in the order to actually consider them

Work the list in order. Skipping straight to "build" because a custom tool feels more controllable is the single most common way a data-quality program spends months of engineering time on something a configuration change would have solved in a week, while the actual problem (missing governance, no owner, no review cadence) stays unsolved regardless of what gets built.

A build that clears this bar still isn't free. Every capability that lands on build needs a named owner, a stated maintenance burden, an observability requirement (how you'd know it silently broke), and a sunset condition (what would make you retire it). A "build" decided a year ago with none of those four recorded is usually unowned code by the time anyone asks about it again.

Score every capability, not just the one that's loudest

A per-capability decision record, not one blanket "we're a build shop" or "we're a buy shop" stance, is what the guide's acceptance bar requires. Different capabilities land in different places:

Notice the pattern: raw data (enrichment source) tends toward buy, because replicating a data provider's coverage is genuinely hard and not your differentiator. Governance logic (eligibility, cost control, adjudication) tends toward build-or-connect, because it's specific to how your business actually operates and generic tools rarely model it well.

Every decision needs the ruled-out paths' reasoning, not just the chosen one

A decision record that only states the chosen path invites the same premature-build mistake later, when someone revisits the decision without the context for why buy, configure, and connect were rejected. Record the reasoning for every path considered, and, for anything that lands on build, the maintenance burden, owner, observability requirement, and sunset condition that make it a bounded decision instead of an open-ended one:

capability: deduplication
decision: configure
decisionCriteria:
  buyRuledOutBecause: null
  configureChosenBecause: Native platform matching plus a review-gated merge process meets the requirement without new tooling
  connectRuledOutBecause: null
  buildRuledOutBecause: The requirement does not need custom logic beyond configuration
maintenanceBurden: null
observabilityRequirement: null
sunsetCondition: null

The three fields below decisionCriteria stay null when the decision isn't build. When it is, they're required, not optional narrative:

capability: enrichment eligibility and cost governance
decision: build
decisionCriteria:
  buyRuledOutBecause: A mature provider's own spend cap caps total monthly spend but doesn't defer individual over-cap requests or gate per-segment eligibility
  configureRuledOutBecause: Native workflow automation can trigger the call at the right moment, but can't atomically check a live spend ledger before each concurrent call without a real data store behind it
  connectRuledOutBecause: A middleware connector can orchestrate the trigger and hold a running counter, but doesn't give reviewers an approval-queue view for ambiguous results without real development on top of it
  buildChosenBecause: Bounded to the atomic spend gate and approval queue specifically; the trigger logic itself stays on native workflow automation, not a full rebuild
maintenanceBurden: A few hours a month reviewing the deferred and flagged-result queues, plus a quarterly ledger-to-invoice reconciliation
owner: revenue-operations
observabilityRequirement: A weekly-reviewed report showing daily spend against the cap, deferred-queue depth, and kill-switch state
sunsetCondition: If the enrichment vendor ships a native per-segment eligibility model with a real-time spend API and defer behavior, retire the custom gate and reconfigure onto the vendor's version

If a later reviewer can't tell why build was ruled out, or can't find who owns a build that was chosen, the decision isn't auditable. The next person facing the same gap either re-litigates it from scratch or, worse, builds the thing again because nobody could find the reasoning that already covered it.

GTM Lab: scoring three broken capabilities

GTM Lab, a fictional B2B software company, is facing three data-quality gaps at once: no reliable deduplication, no enrichment eligibility governance, and no sequence-orchestration safety net. Scoring each, in order, with build bounded wherever it's the answer:

Deduplication. No mature standalone tool matches the required adjudication-tier logic without heavy customization, but that customization turns out to be unnecessary: native matching rules plus a review-gated merge process already cover the requirement. Configure. No build, no maintenance record needed.

Enrichment eligibility and cost governance. A mature provider's own spend cap was worth checking first (buy): it caps total monthly spend, but doesn't defer individual over-cap requests or gate per-segment eligibility. Native workflow automation (configure) can trigger the call at the right moment on its own, but can't atomically check a live spend ledger before each concurrent call without a real data store. A middleware connector (connect) can orchestrate the trigger and hold a running counter, but doesn't provide an approval-queue view for ambiguous results without real development on top of it. None of the three meets the specific requirement: an atomic, real-time spend gate with a defer-not-drop rule and an approval queue. Build, bounded to that gate and queue. The trigger logic itself stays on native automation. Owner: Revenue Operations. Maintenance: a few hours a month reviewing the deferred/flagged queues plus a quarterly ledger reconciliation. Observability: a weekly spend-vs-cap and deferred-queue report. Sunset: retire the custom gate if the vendor ships native per-segment eligibility with a real-time, defer-capable spend API.

Sequence-orchestration reconciliation. No off-the-shelf tool models GTM Lab's own disqualification and customer-status rules directly (buy, ruled out). Native automation alone can't reconcile two systems' membership state on a recurring basis (configure, ruled out for reconciliation specifically). The sequencing tool's native CRM integration (connect), once actually checked, already handles the standard cases. It removes people from a sequence on unsubscribe and on closed-won. What it doesn't recognize is GTM Lab's own lifecycle fields, which aren't standard states the connector knows about. Connect, plus a bounded custom rule layer that checks those specific fields against sequence membership, not a ground-up build. Owner: Sales operations, since the layer reads Sales-owned lifecycle fields. Maintenance: update only when those fields change shape. Observability: a monthly count of enrollments the layer held or removed, reviewed for false positives. Sunset: retire the layer if the connector adds custom-field- aware reconciliation natively.

Deduplication resolves without writing anything custom. The enrichment gate justifies a genuinely bounded build, with its owner and exit condition on record from day one. The sequencing capability resolves mostly to the native connector GTM Lab already has, with only a thin rule layer on top of it, not a system built from scratch. Where GTM Lab does build, the design pattern is documented in DIY CRM Database Health Center architecture.

This is a worked example. GTM Lab's specific scoring outcomes depend on tools and constraints that are operating choices, not a universal answer for every business.

Build-versus-buy checklist

• Every capability under consideration has an explicit decision: buy, configure, connect, or build.
• The reasoning for every ruled-out path is recorded, not just the chosen path's reasoning.
• Build is chosen only where buy, configure, and connect are each shown, specifically, to fail the requirement, and only for the specific gap they fail, not the whole capability.
• Every build decision names a maintenance owner, a maintenance burden, an observability requirement, and a sunset condition.
• Raw data/coverage gaps default toward buy; business-specific governance logic is evaluated on its own merits rather than assumed to require a build.
• The decision record is revisited on a stated cadence, since a "build" decision made a year ago may be obsolete once a vendor closes the gap.

Where this connects

Where a capability's decision lands on "build," the reference architecture for what a credible custom data-quality system looks like is DIY CRM Database Health Center architecture. The baseline findings that surface which capabilities need a decision at all come from CRM data quality audit.