How to Choose

CDP: build or buy — a decision frame for the operator

CDP vendors show 'everything out of the box', the build team promises 'unique fit'. The real choice is between speed, ownership and 5-year licensing economics.

Discuss Your Challenge

When the fork appears

The CDP initiative is mature. The CMO wants it faster. The CTO wants ownership. The CFO wants clear TCO. Vendors (Tealium, Treasure Data, Bloomreach, Twilio Segment) pitch a 6-week pilot. Internal data engineering says: “we have the foundation — in 9 months we will build for ourselves”.

The choice is not obvious. Often it is taken on political grounds rather than a systematic framework.

Frame criteria

Time to first value. Buy: 3-6 months to the first working use case. Build: 9-18 months. If the business needs demonstrable value fast — buy wins.

Uniqueness of requirements. If your requirements are standard (identity resolution, segment activation, basic personalisation) — buy fits. If you are a telecom with a unique combination of biller events / network signals / multi-line accounts — build may be justified.

Base size and cost per profile. Buy vendors often charge per profile. At 5M customers this can become material. Calculate 5-year TCO, not the first-year licence.

Internal data engineering speed. Buy = paid the vendor. Build = need a team of 8-12 people that builds and runs it for 5+ years. Be realistic about whether you have that team.

Regulatory specifics. If PII cannot be exported (data residency), some buy vendors are out. On-prem vs cloud — a separate criterion.

Lock-in tolerance. Buy creates contractual lock-in — price hikes after 3 years, limited exit. Build creates expertise lock-in (if your team leaves, everything falls).

Where decisions usually go wrong

Buy under the banner “we do not have the team”. A year later the team is not hired, the vendor raises prices — the operator is stuck between two stools.

Build under the banner “everything is unique”. 18 months later you have a generic CDP with retro design, losing to a baseline vendor.

Pilot a vendor on one use case, then “we will expand to everything”. On the pilot the vendor shows the best, at full load — different story.

Comparison by feature list, not by the real business job to be done. The vendor has 200 features, 90% not needed.

Ignoring integration debt. Any CDP — buy or build — requires integration with biller, CRM, channels. That is often 60-70% of effort, and does not depend on build/buy.

When buy

Base <2-3M customers. No specific data residency requirements. Small data engineering team (<5 people). Need for speed (launch in 3-6 months).

Use cases are standard: marketing automation, basic personalisation, segment activation.

When build

Significant base (>5M). Telecom-specific identity resolution requirements. Strong existing data engineering team. Regulatory constraints on cloud / data export. Long-term horizon (5+ years).

When hybrid

Often optimal: buy for the quick-win frontend (audience builder, segment activation), build for the long-term backend (identity resolution, profile store) with a migration path. Vendor becomes the UI layer, internal — the data layer.

What to discuss at the committee

What is the 5-year TCO for each option (including cost per profile, integration, run cost, exit cost)?

Which use cases in the first 12 months? Which in the first 36?

Realism of hiring the data engineering team in the build scenario.

Vendor financial stability — who will be around in 5 years.

Exit story — what to do in 3 years if the choice turns out wrong.

How SamaraliSoft helps

CDP Decision Workshop — 3-4 weeks. Sizing requirements, TCO modelling for build / buy / hybrid scenarios, vendor longlist + shortlist evaluation, risk assessment, recommendation with justification.