Build vs. Buy: What It Actually Takes to Build In-House Ad Automation

Building in-house ad automation is not one project. It is five, and each can stall the others. Integrations with six separate ad platform APIs, Google Ads, Meta, Microsoft Ads, TikTok, AppLovin, and OpenAI's ChatGPT Ads, each with its own auth model, rate limits, and reporting quirks. A measurement and reconciliation engine, because those platforms disagree with each other and with your CRM. A permissions and guardrail layer built to the standard of the execution logic. The execution logic itself. And a grading layer that says whether each change worked, which almost nobody scopes at the start. Then you maintain all five, indefinitely.

Here is the part that catches executive sponsors off guard. The first four are engineering problems with known shapes, and a competent team estimates them roughly right. The fifth, deciding whether a change actually improved anything, is not an engineering problem. It is a measurement-design problem, and it decides whether the system produces learning or just activity.

What are you actually building, component by component?

Five systems. Scope them separately, because they fail separately.

Why isn't six integrations just one integration times six?

Because the shared surface between them is close to zero. Three things differ on every platform, and each one is a source of ongoing work.

Authentication and access approval. Google Ads requires a developer token with its own approval tiers on top of OAuth. Meta requires app review for ads management permissions plus business verification. Microsoft Ads has its own developer token and OAuth flow. TikTok requires app approval through its marketing API program. AppLovin works differently again. None are hard individually. Collectively they are a multi-week approval track engineering cannot compress by writing better code, because the gating step is another company's review queue.

Rate limits and quotas. Each platform meters differently, some on requests, some on operations, some on a cost-per-call model where a heavy report query consumes far more quota than a simple mutation. Your sync architecture has to be designed around the strictest of the six, or degrade per-platform. Getting this wrong does not produce a clean error. It produces intermittent partial data that looks like a reporting bug for weeks.

Reporting semantics. Field names, metric definitions, aggregation levels, and currency handling differ. So do the clocks, each platform reports in its own configured time zone, so "yesterday" is not the same 24 hours everywhere.

When this is less painful than described: if you need two platforms and read access only, this section overstates your problem. A read-only, two-platform reporting pipeline is a reasonable in-house build. The scope explodes at write access, and again at platforms five and six.

Why does the measurement engine turn into its own product?

Because the platforms are not wrong in a way you can correct. They are measuring different things and reporting them with equal confidence.

Google Ads defaults to a 30-day click attribution window. Meta defaults to 7-day click. A conversion both platforms claim is not a data error, it is two systems correctly reporting under their own rules, on their own clock. Both also use modeled conversions, so part of what you are reconciling is an estimate that changes as the model updates.

Your reconciliation engine therefore has to make and defend a series of decisions: which attribution window is canonical, how you deduplicate a conversion claimed twice, how you join platform data to CRM records that arrive late and get corrected, what happens when a platform restates last week after you reported it, and how you present a number that will never match any platform's UI.

That last one is the organizational problem hiding inside the technical one. Someone senior will ask why your number disagrees with the Google Ads interface. If you cannot answer in one sentence, the engine does not get trusted, and an untrusted measurement layer is worse than none.

What this is NOT: a data warehouse project. Landing six platforms' data in one warehouse is the easy half, routinely mistaken for the whole job. Deciding what the numbers mean when they conflict is the half that takes the time, and it cannot be delegated to a pipeline.

What does the guardrail layer have to do, and why can't it come later?

A system that can spend money needs controls built to the same standard as the thing being controlled. Minimum viable set:

• Budget caps enforced at execution time, not checked afterward in a report.
• An approval gate no code path can bypass, including retries, backfills, and admin tooling.
• A spend ledger, a durable record of what changed, when, by whose approval, and what it cost.
• A kill switch a non-engineer can trigger at 11pm without filing a ticket.
• Role-based permissions, so whoever can approve a change is not necessarily whoever can raise the cap.

Sequencing matters more than the list. Teams routinely ship execution first and plan guardrails for v2, because execution is the part that presents well to a steering committee. That order produces exactly the artifact your board worries about: write access to ad accounts with no enforced ceiling. Retrofitting an approval gate into a codebase not built around one means auditing every write path to prove none skips it, more work than building it in from the start.

The edge case worth naming: the kill switch is harder than it looks. Stopping new execution is easy. Deciding what happens to changes in flight, queued for a platform's async processing, or applied and awaiting measurement is a design question, and "stop everything and leave the account half-changed" is not an acceptable answer at an executive level.

What is the fifth build nobody scopes?

The grading layer. To say a change worked, you need four things in place before it ships:

• A stated hypothesis. A falsifiable prediction recorded in advance, "shifting 15% of budget from this ad group to that one lowers blended CPA without reducing volume." Recorded afterward, it is not a hypothesis. It is a narrative.
• A pre-declared window and metric. Chosen before the result is visible, so nobody picks the window that makes the change look good.
• A comparison that accounts for everything else moving. Seasonality, other simultaneous changes, platform-side algorithm shifts. This is why "did this change work" is a harder question than "what happened after this change."
• A revert path. A verdict of "hurt" is only useful if something undoes the change.

Most in-house builds ship a timeline of changes next to a performance chart and leave a human to infer causation, which is what your team was already doing in spreadsheets, now with better tooling and the same epistemics.

What does maintenance cost after launch?

The build is a project. The maintenance is a permanent line item, and it is the number most build cases leave out.

Ad platform APIs version and deprecate on published schedules, Google Ads ships multiple versions a year and sunsets older ones, and Meta's Marketing API versions expire on a published cadence too. That is not instability. It is normal and announced. It means a fraction of an engineer is committed to this system forever, producing no new capability: migrations, field deprecations, new required parameters, changed enums, and the occasional semantics change that silently alters what a metric means.

Model it with your own numbers. Say a fully loaded senior engineer costs $220,000 a year, about $18,300 a month. Two engineers for nine months to a working multi-platform system with guardrails is roughly $330,000 of loaded cost, before the grading layer, which usually gets scoped as a phase two that arrives late or not at all. Then assume half an engineer permanently on maintenance: about $110,000 a year, every year, for the system to keep doing what it already did.

Those figures are a model, not a quote. Substitute your own loaded cost and your own honest timeline. The timeline, not the rate, is the input most likely to be wrong.

When does building in-house genuinely win?

Three situations, and pretending otherwise would be the kind of vendor argument this post is trying not to make.

Proprietary attribution tied to an unusual business model. If your economics depend on a conversion definition no vendor models, long enterprise cycles with partner-sourced revenue, a marketplace where the valuable event happens months after the click, a subscription judged on contribution margin at month 18, then the measurement engine is your differentiation. Building it is not overhead. It is the product.

Data residency or regulatory constraints a vendor cannot meet. If regulation requires ad and customer data stay in a specific jurisdiction or inside your own infrastructure, and no vendor will contract to it, the decision is made for you.

Idle engineering capacity with a long time horizon. If you have engineers whose alternative use is low-value and a multi-year horizon to absorb build plus maintenance, the opportunity-cost argument weakens considerably. Be honest about "idle," though, engineers are rarely idle, just assigned to something less visible.

Build vs. buy, side by side

Where this table flatters buying: a vendor's attribution decisions are already made, which is an advantage right up until they are made differently than you would have made them. Ask any vendor, including us, exactly how conversions are deduplicated across platforms and which window is canonical. If the answer is not specific, the "already decided" column is not the advantage it looks like.

How should an executive frame this decision?

Not as a cost comparison. Build-versus-buy spreadsheets set a build estimate against a subscription price and miss the two inputs that decide it.

The first is time to first graded verdict, not time to first executed change, an easy milestone that proves little. That date is when learning starts compounding; every month before it is activity without accumulation.

The second is who absorbs the variance. API changes, rate-limit surprises, a semantics shift that quietly breaks reconciliation. If you build, that lands on your engineering roadmap, unpredictably, forever. If you buy, it is the vendor's problem and your exposure is the subscription plus switching risk. A real trade, not a free lunch, and the one worth putting in front of a board.

Frequently asked questions

Scope the build honestly, six integrations, reconciliation, guardrails, execution, and grading, then compare it against a loop that already runs all five.

Related reading

• How small agencies increase their margins with AI
• Scale paid media without hiring
• Incrementality testing