The build-vs-buy question in martech has a standard answer: "it depends." That is true but useless. The better question is: what does building actually cost, fully loaded, and are you accounting for all of it?

Most teams undercount. They price the licences. They forget the integration work, the ongoing maintenance, the analyst time spent bridging systems that do not talk to each other, and the opportunity cost of capability gaps that persist for months while the stack is assembled.

This article is an honest attempt to lay out those costs, so the comparison with an integrated platform is fair.

The point-tool model and how it accumulates

A typical in-house martech stack for a mid-sized team running paid media across two or three channels includes: a DSP or managed access to platform UIs, a bid management tool, a data warehouse or connector (something to pull everything into one place), a reporting layer, a creative testing tool or process, and some form of attribution solution.

Each of these is a separate vendor relationship, a separate contract, a separate renewal cycle, and a separate API integration to maintain. They were not designed to work together. They can be made to work together, with effort.

That effort is the hidden cost.

Integration: the cost nobody budgets for upfront

Getting data out of five platforms and into a single source of truth is not a one-time project. It is an ongoing maintenance obligation.

Platform APIs change. Schema updates break pipelines. A new campaign type in one platform does not map cleanly to your existing data model, so someone has to extend it. A new channel requires a new connector. An attribution vendor changes its methodology, and three months of data requires reprocessing before it is comparable to the three months before it.

Analyst and engineering time spent on pipeline maintenance is not glamorous, and it does not appear on any martech vendor's pricing page. In practice, teams running complex multi-platform stacks spend a material portion of their data team's capacity on infrastructure rather than analysis. Conservative estimates from practitioners put this at 20 to 40 per cent of data team time. At senior analyst or data engineer rates, that is a significant number annually before anyone has drawn an insight.

The headcount model

Point tools require people to operate them. A DSP requires a trader. A bid management tool requires someone who knows how to configure rules and interpret its outputs. A reporting layer requires someone to build and maintain dashboards. Attribution requires someone who understands the methodology well enough to challenge it when something looks wrong.

In a large team, these roles exist and the stack is efficient. In a mid-sized team, these roles overlap, and each person carries a broader surface area than they can cover deeply. The result is not incompetence; it is coverage gaps. Campaigns that are not watched closely enough. Bid rules that are not updated when conditions change. Reports that are not queried because no one has time.

Headcount cost is the largest line item in any honest build analysis, and it compounds with scale. As media spend grows, the tooling can usually handle it. The people cannot, without adding more people.

The latency problem

A stack assembled from point tools has latency built into it. Data moves between systems on schedules: nightly syncs, hourly API pulls, weekly exports. Decisions are made on data that is hours or days old. By the time a report surfaces a problem, the problem has been running for a while.

This is not a criticism of the individual tools. It is a structural consequence of connecting systems that were not designed to share state. Integration adds latency at every seam.

The practical cost of latency is difficult to quantify precisely, but it is real. Campaigns that run at suboptimal settings for 24 hours because no one saw the signal until the next morning. Creative that fatigues for a week before a weekly report surfaces the decay. Budget that paces incorrectly on a high-traffic day because the pacing tool is working from yesterday's data.

Capability gaps and the roadmap problem

A stack of point tools is only as capable as the union of what each tool does. When a capability does not exist in any of your tools, you have three options: build it internally, wait for a vendor to release it, or go without it.

Building internally is expensive and slow. Waiting for vendors means your roadmap is determined by someone else's priorities. Going without it means accepting a capability gap, sometimes for a long time.

Integrated platforms have a different tradeoff. You are dependent on one vendor's roadmap rather than five, which concentrates the risk. But the capability is built to work with the rest of the system from the start, rather than bolted on later.

The honest cost comparison

A genuine build-vs-buy comparison should include, on the build side:

  • Licence costs for each point tool (sum of annual contracts)
  • Integration development and ongoing maintenance (engineering time, at loaded cost)
  • Data pipeline infrastructure (warehouse, connectors, compute)
  • Analyst and operations time spent bridging systems
  • Capability gaps: what you cannot do, and what that costs in performance terms
  • Vendor management overhead: renewals, support escalations, contract negotiations

On the buy side, for an integrated platform:

  • Platform licence (typically a flat fee or percentage of spend)
  • Onboarding and implementation time
  • Ongoing vendor dependency risk

Most honest comparisons find the gap narrower than expected, and sometimes reversed entirely once integration and headcount costs are included. The integrated platform rarely wins on headline price. It often wins on total cost of ownership once the hidden costs are surfaced.

When building makes sense

There are cases where building is the right answer. If your requirements are sufficiently unusual that no platform covers them, building is rational. If you have the engineering capacity and a genuine strategic need to own the infrastructure, building creates a defensible asset. If you are operating at a scale where platform fees become significant relative to the custom build cost, the maths may flip.

None of those conditions describe most mid-sized agencies or in-house teams. Most are assembling point tools not because it is strategically optimal, but because it is how the industry has always worked, and because the full cost is invisible until it has been running for two years.

The question to ask yourself

Not: can we build this? Almost any team can assemble a workable stack from point tools.

The question is: what would we do with the engineering hours, the analyst capacity, and the management attention that the stack currently consumes? If the answer is "something more valuable than maintaining data pipelines," the case for an integrated platform deserves a serious look.

The cost of building is not the tools. It is what you trade away to keep them running.