Customer Data Platforms (CDPs) are defined as “packaged software” by The CDP Institute, so it’s literally impossible for a company to build its own CDP. But, definitions notwithstanding, many potential CDP buyers do consider building the equivalent of a CDP for their own use from ground-up. The question seems to have come up more frequently in the past year, perhaps because CDPs are now well enough understood that IT departments can develop reasonable specifications for what would be needed. So the build vs buy software debate, which once seemed decisively settled in favor of buying, is now back on the agenda.
Build vs Buy?
In fact, the debate never really went away. Surveys show that a substantial portion of firms have always built their own CDP. It’s hard to interpret such data because we don’t usually know how the respondents are defining what a CDP is. Clearly they are not following the CDP Institute definition, let alone the Institute’s more detailed RealCDP checklist, which requires a CDP to accept all types of data, retain all details indefinitely, construct unified profiles with a single customer view (SCV), permit external real-time access to the profiles, and support real-time event triggers. In many cases, respondents seem to define a CDP as any central repository for customer data, including systems that are considerably less powerful than the Institute’s definition requires.
There’s more at stake than legalistic hair-splitting. Building a true CDP is a serious technical challenge, while standing up a simple database is not. It’s reasonable to assume that many IT departments see the CDP as a minor extension of an existing data warehouse or data lake. Some even argue their current CRM already does what a CDP is supposed to do. Starting from those premises, they argue that the build option is faster, cheaper, and easier than buying, installing, integrating, and supporting a massive new system.
Potential CDP users are often less confident than IT that an internal solution will meet their needs. Even if they share the same understanding of CDP as the IT department, they are less certain that the IT team will deliver the promised system on time, one budget, and with all the desired features. Business users also often see a purchased CDP as a way to reduce reliance on the IT team for day-to-day operation of the system and for future enhancements. This is one of implicit promises of “packaged software” and one of the reasons that CDPs have gained such popularity in the first place.
It’s nice to think every build vs buy software decision will be based on a thorough, objective comparison of the two options. But many companies have strong cultural or political biases that favor one option or the other. In those cases, the details of CDP requirements are less important than the impressions that powerful decision-makers have of the scope of the project. This is where definitions become important. IT departments that see the CDP as a simple project are likely to insist that they build it themselves, while those same departments might eagerly purchase a system if they see building it as a major drain on their resources.
The Scope of Building a CDP
One way to clarify the scope of the CDP is to define the full set of capabilities needed to deliver a functional system. This list starts with capturing data from source systems and ends with distributing data to systems that use it. Each capability is a major application that relates to an existing software category. So, a company proposing to build its own CDP is really proposing to create its own version of many major systems – an undertaking that few would really accept if given the simpler alternative of buying one package that combines them all.
Check out How To Choose the Right CDP For You
The calculation changes considerably if a company already has some of the CDP components in place. An existing data lake would already include data capture, pipeline, and database capabilities. Existing customer systems might have data quality, identity resolution, and master data management features. Data science and business analytics teams may have heavy investments in analytics, segmentation, and reporting tools. And a substantial customer journey orchestration backbone may already be in place to share data and processes across systems.
So even an IT department that correctly understands the scope of work might still conclude the incremental effort to build a CDP is less than the effort to install, integrate, and maintain an entirely separate system. This isn’t necessarily true. The CDP will likely require adding new data sources and processes to existing applications, so the incremental effort using existing tools may be substantial. This requires detailed analysis to determine. Absent that analysis, buying a CDP that replicates many existing functions seems duplicative and wasteful.
Inventory of CDP Features for Build vs Buy
So far, we’ve only been considering the development costs of build vs buy a CDP. Yet development cost is just one factor in making the choice, and not really the most important. A more comprehensive inventory of would include:
- Current Features
Is there some feature missing from existing packaged systems that would provide substantial competitive advantage if it were provided by a company-built system? If so, that would be a strong reason to build (assuming the IT team can deliver the special feature). The other side of this question is whether an existing packaged system provides all the functions needed for current CDP requirements. If not, you might need to build your own CDP to acquire required features that don’t add competitive advantage.
- Future Features
IT departments often argue that they can add new features as new needs appear, giving the company more control over its future than relying on the packaged software vendor to add them. This is an appealing argument but must be balanced against the question of how quickly the IT department will really make the changes, given other demands on its limited resources. Balance this against the strong probability that a packaged system will be enhanced more frequently than an in-house product, and may add the new features before the company realizes it needs them.
- Financial Cost
Most build vs buy analysis compares the cost of developing a new system against the cost of buying a new package. But full financial costs also include ongoing maintenance and updates of the home-built system, and costs to integrate and staff operations of the package. Also bear in mind that the CDP may take over some tasks currently handled by existing systems or manually, resulting in considerable staff time and cost reductions. (Pro tip: those savings alone may justify the cost of a packaged CDP.) Be sure to include all these in your calculations.
- Opportunity Cost
Is the CDP project the best use of the company’s development resources? Even if budgets are limitless, there is a limited number of people who understand the company systems well enough to design a proper CDP and of managers and business users to help them. A counter-argument is that better packaged systems could come along in the future, perhaps from one of your current software vendors, so it might make sense to build a stopgap in-house solution until that happens. But be careful of this logic. Temporary stopgaps have a way of becoming stubbornly permanent over time.
- Risk and Time to Value
There is always a substantial risk that an in-house project will take longer, cost more, and deliver less than promised. Apart from the direct costs, such delays mean a longer wait before the company reaps the benefits of its CDP or solves the problems it is meant to correct. This isn’t to say that buying is risk free. There are always concerns that the purchased system won’t perform as promised or won’t be able to scale as future needs require. Reducing these risks is one of the reasons that companies need to create detailed requirements and thoroughly test any purchased system against them before signing a contract.
Final Thoughts
No company truly builds its own system from scratch. You won’t build your own chips, servers, or operating system, and you’ll almost surely use a commercial or open source database. Many other components may already be present or be bought for the project. Purchased components reduce the cost and risk of the home-built project, although each component adds integration and license costs. Similarly, no packaged system is truly complete. There will likely be some custom connectors to integrate with existing systems, and IT support is always needed for the installation and integrations.
So while there is certainly a major difference between building vs buying your CDP, you should also recognize that there is some overlap between the two approaches. For the greatest chance of success, replace “build vs buy” with “what to build and what to buy” and set your goal as finding the optimal mix of built and purchased components.
