The Question Is Never That Simple
Every few months, someone in a marketing or product org gets asked the same question. Sometimes it comes from a senior leader who just saw a competitor launch a personalization experience that should not have been possible. Sometimes it comes from a CFO who just ran the numbers on the combined licensing cost of the CDP, the journey orchestration platform, the experimentation tool, and the feature flagging service, and would like an explanation. The question is always framed the same way: do we build this ourselves, or do we buy a tool that already does it?
Reasonable question, but almost never the right one.
Because the framing assumes two things that are almost never true at the same time. That building and buying are mutually exclusive paths. And that your team is equally capable of evaluating both options honestly. In practice, most teams are biased toward one before the conversation starts. Engineers want to build. Finance wants to buy. Product is usually caught in the middle, nodding at whoever made the last slide.
And then there is the third team. The one that is often loudest, often most urgent, and often least represented in the final decision. Marketing. They are the ones with a product launching in six weeks, a personalization requirement the current CRM cannot handle, and a very reasonable question: why does this take so long? They do not care whether the data sits in Segment or a homegrown CDP. They care whether the right message reaches the right person at the right moment, whether experimentation results come back in days and not weeks, and whether the whole thing scales when the campaign actually works. A campaign that outperforms expectations, running on infrastructure not designed for the volume, is not a good problem to have.
The real question is more uncomfortable than any of these three teams wants to sit with. What does our organization actually know how to do right now, what does the business need right now, and how honest are we being about the gap between those two things? In MarTech, that gap is often enormous. The category moves fast. Vendors are consolidating. AI is reshaping what personalization and analytics even mean. And the teams making these decisions are frequently operating on information that is twelve to eighteen months out of date.
When Engineers Want to Build Everything
There is a joke that engineers tell around the time someone suggests buying a new MarTech tool. We could build that in a couple of sprints. The thing is, they are not joking. A reasonably talented engineer looking at a CDP or a journey orchestration platform will immediately decompose it into its component parts. The event ingestion layer. The identity resolution logic. The audience segmentation API. The delivery connectors. They run a rough calculation, usually wildly optimistic, and conclude the product is mostly plumbing they already know how to do.
What they are not calculating is everything that makes the product actually work for real marketers over time. The edge cases in identity stitching that took the vendor four years to discover. The compliance and consent management that is genuinely hard. The on-call rotation for keeping the event pipeline up at 2am when a campaign fires. The delivery rate optimization that only comes from sending billions of messages and learning from every bounce. All of that invisible labor lives inside a mature MarTech product and is completely absent from the sprint prototype.
Engineers are trained to solve problems with code. The instinct to build is also a sign of confidence, and that confidence is valuable. But confidence and judgment are different things, and the difference is usually about eighteen months of production experience and a few post-mortems nobody wants to repeat.
The other thing engineers underweigh, almost universally, is migration cost. Building a homegrown analytics pipeline is one decision. Replacing it later, when the business has built three years of campaigns and workflows on top of it, is a completely different and much harder one. Every day a custom-built system runs in production, it accumulates integrations, dependencies, and data that lives in its schema. When the time comes to move off it, none of that migrates cleanly. It migrates painfully, slowly, and usually with at least one weekend where someone is watching the DAM export job and praying the rollback works.
The best engineering leaders are the ones who are equally proud of the things they chose not to build. You cannot demo a decision not to build a custom CDP. But the cumulative effect of those decisions, over years, is usually the difference between a MarTech stack that enables the marketing team and one that holds them hostage to an engineering queue.
Why Product Teams Default to Buying
Product managers have a different scope. Their entire professional identity is built around shipping things quickly, validating assumptions, and moving on. Buying a MarTech tool collapses the timeline dramatically. You can go from identifying a need for a Customer Data Platform to having one in production in weeks, not quarters. In a lot of contexts that is exactly the right call.
When you buy a tool to solve a problem quickly, you are also buying its constraints. Its data model. Its identity resolution logic. Its API rate limits, pricing tiers, and roadmap. You are betting that the vendor’s vision of what a CDP or a journey orchestration tool should do is close enough to yours that the gaps will never matter. Sometimes that bet pays off for years. Other times it pays off until the marketing team needs a segmentation logic the vendor has had in their backlog since 2022 and you have no leverage to move it.
There is a subtler problem too. When a product team buys too many MarTech tools too quickly, the stack becomes a collection of integrations rather than a coherent system. The DAM does not talk to the CMS cleanly. The CDP’s identity model does not match the CRM’s contact model. The experimentation tool cannot consume feature flag state from the feature flagging service. Every gap gets papered over with a custom integration, and suddenly there are twelve integrations that nobody fully understands, all of which break in slightly different ways when any vendor ships a major update. The marketing team cannot run a cross-channel journey because the data is in three different systems with three different definitions of what a “user” means.
And then comes the migration question, which product teams almost never plan for adequately. The conversation usually goes: we will cross that bridge when we get there. The bridge turns out to be a five-month project that requires freezing the data model, running two CDPs in parallel, mapping identity graphs across both, and reconciling historical event data that was stored differently in each system. Buying to move fast is a legitimate strategy. Buying without thinking about what moving away looks like is just deferring a harder problem to a version of your team that has less time, more pressure, and a business that is now depending on the thing you are trying to replace.
When Marketing Enters the Room
The marketing team is usually right about what they need. They are wrong about how long it takes to get it, and engineering is usually wrong about how urgent it actually is. Both sides are working with incomplete information, and the gap between them is where most of the organizational friction lives and most of the MarTech budget gets wasted.
A marketing team planning a personalization campaign does not care whether the underlying data pipeline runs on a homegrown event store or on Segment. They care whether the right audience gets the right content at the right moment, whether the analytics come back fast enough to optimize mid-flight, and whether the whole thing scales to the volume they are expecting if the campaign performs. They also care about being able to iterate without filing an engineering ticket every time they want to change a segment definition or add a content variant. The ability to move at campaign speed rather than sprint speed is not a nice-to-have. It is the difference between a marketing team that tests ten ideas a month and one that tests two.
The scalability question is where marketing and engineering most frequently talk past each other. Engineering thinks about scalability in terms of technical architecture: can the system handle the throughput? Marketing thinks about it in terms of outcomes: can we do more of what is working without the wheels falling off? A technically elegant personalization engine that requires a developer to configure every new audience rule is not actually scalable from a marketing perspective. A vendor tool that a marketing manager can configure in an afternoon, without touching a codebase, is extremely scalable from a marketing perspective, even if the engineer would be embarrassed to present it at a systems design interview.
The other thing marketing brings to this conversation, and rarely gets credit for, is a clear-eyed view of what competitors are doing right now. When a competitor ships a new channel or a tighter integration between their CRM and content delivery layer, the marketing team feels it in open rates and conversion data almost immediately. Engineering feels it eventually, when the roadmap conversation comes around. Some of the best buy decisions I have seen were made because a marketing team said: our competitor is running journey orchestration through Braze and it is working for them, and the product team was honest enough to say: that is a legitimate signal, and we do not have time to build a better version before it costs us customers.
The improve-over-time requirement gets underweighted in almost every initial evaluation. Marketing does not just need something that works today. They need something they can get smarter about. A DAM that starts with basic asset tagging but grows into AI-assisted content recommendations. An analytics setup that starts with pageview tracking but evolves into behavioral cohort analysis. An experimentation platform that starts with simple A/B tests and eventually supports multi-armed bandits across channels. If the tool you buy has a ceiling the business will hit in eighteen months, you are not buying a solution. You are buying a temporary reprieve and a future migration problem at the same time.
The Two Paths Nobody Talks About
The conversation usually stops at the binary. But there are two other moves that experienced MarTech teams make, and they are worth naming because they are the ones that actually reflect how mature organizations operate.
Build-Then-Buy and Buy-Then-Build
The conversation usually stops at two options: build or buy. There are actually four, and the two nobody discusses are often the ones that fit best.
Build-then-buy means you start with a homegrown solution, ship quickly with what your team can produce, and buy a mature vendor product once the category is well-understood and the business requirements have stabilized. This is not a failure state. This is a deliberate strategy for capability areas where you need to move before a mature solution exists, or where the requirements are so unique that no vendor product fits yet. The risk is that the homegrown solution grows in complexity faster than expected, the team gets attached to it, and the migration window keeps slipping. Every month a custom CDP runs in production is another month of events in a schema only your team fully understands.
Buy-then-build is the inverse. You buy a vendor tool to move fast, use it to understand what you actually need, and build custom capability on top of it or around it once you know where the gaps are. This is the right strategy when the category is mature and you can get real value from a vendor product immediately, but you know your use case will eventually outgrow it. The risk here is that the vendor tool becomes load-bearing infrastructure. People build campaigns on top of it. Integrations pile up. The custom layer you planned to build on top of it ends up coupled to its quirks, and what was supposed to be a foundation becomes a dependency you cannot remove without a migration.
Migrations in MarTech are rarely like the whiteboard diagram suggests. Running two systems in parallel while the new one proves itself is expensive and error-prone. Identity graphs built on different models produce different audience definitions. Historical event data stored in the old schema does not map cleanly to the new one. If the migration involves a live CDP or a real-time personalization engine, there will be a moment where some subset of users gets the wrong experience because the two systems disagree about who they are. The teams that handle this well plan for the overlap before they start, not after they are already in it.
None of this means you should avoid migration. Sometimes you have no choice. But it does mean the decision you make today about whether to build or buy has a much longer tail than it appears to in the room where you are making it.
Leave a Reply