Build the connector or buy it

Buy the connectors for platforms a vendor already supports. Build only the sources nobody sells you. That holds for most agencies and most mid-market marketing teams, and the reason has nothing to do with whether building is difficult.

Building the first version is easy. A competent developer pulls a week of ad platform performance data into a table in two or three days, and it works. The cost that decides this question shows up much later, when the API version you targeted is retired, the developer has moved on, and the report finance depends on is quietly producing zeros for three campaigns.

So the honest comparison is not build cost against subscription cost. It is build cost plus maintenance against subscription cost, over the life of the pipeline, at a rate you actually pay people. That reframing flips the answer more often than any technical argument does.

It also flips it per source rather than per portfolio, which is the second thing teams get wrong. The right decision for Google Ads and the right decision for a regional out-of-home network are not the same decision.

Authentication comes first: obtaining a token, refreshing it before it expires, and handling the account hierarchy so a single credential can reach every client account you manage. This surface changes when the platform changes its consent model, which it does without asking you.

Extraction is second: calling the reporting endpoint, paginating through results, respecting throttles, and coping when a field is renamed or a metric is redefined. Every platform publishes the rules you have to code against, and the Google Ads API documents its limits and quotas explicitly. Those limits are not suggestions, and they change.

Scheduling and retry is third: running on a cadence, backing off on a transient failure, and reloading the trailing window that ad platforms restate as conversions attribute back.

Loading is fourth, and it is the only stable part, because you own the destination. Nobody deprecates your own table. That asymmetry is the whole argument: three quarters of a connector is owned by someone whose roadmap you do not control.

Row three is the line that gets omitted most often. Platforms retire API versions on a published schedule, and a connector targeting a retired version does not degrade gracefully. It stops, or worse, it keeps running and returns partial data.

Row six is the one people underestimate emotionally rather than financially. Being the named person for a pipeline you built is a real ongoing tax on attention, and it is paid by whoever is most senior, because they are the one who can fix it.

Row eight is the honest argument in favour of building. A vendor connector portfolio is switching cost you cannot see until you try to leave, and the day you try to leave is usually the day the vendor changes its pricing model. Owning the code means the exit is a migration rather than a rebuild.

Row seven is the argument that decides high-volume cases. Per-row pricing is fine at ten million rows a month and ruinous at four hundred million, and event-level exports cross that line faster than aggregate reports do.

Assume a blended internal cost of $95 an hour. That number should be yours, not mine, and it comes out of the same exercise as an hourly rate card: fully loaded salary, not billable rate, because this is cost rather than revenue.

Build side, one source. Initial implementation at four days is 32 hours, so $3,040. Ongoing maintenance at three hours a month is $285 a month, so $3,420 a year. A deprecation rework every fifteen months at twelve hours is $1,140, which annualises to about $912. Year one lands at roughly $7,372. Year two, with no build cost, lands at roughly $4,332.

Buy side, same source. Configuration is an hour, so $95, plus whatever the subscription is quoted at. Set the two equal and the break-even subscription is about $360 a month in year two, and higher in year one.

That is not a verdict, it is a template. Put your own rate in, put your vendor's actual quote in, and run it once per source. The three-hours-a-month figure is the one to argue about, and the way to settle it is to look at how many hours the connectors you already maintain consumed last quarter.

One caution on the maintenance estimate. Three hours a month is an average across a year that contains one bad month. If you have never had the bad month, your average is optimistic rather than accurate.

There are four cases where building wins on merit rather than on stubbornness. The first is a source no vendor supports: a client's proprietary booking system, a regional ad network, a call tracking platform with three hundred customers. There is no subscription to compare against.

The second is a field the vendor's connector does not expose. Vendors normalise, and normalising means dropping. If your attribution work depends on a dimension the vendor flattens away, buying gets you a table that cannot answer the question.

The third is volume crossing the pricing line described above. The fourth is a data residency or contractual constraint that stops the records passing through a third party at all, which comes up with health and financial clients more than people expect.

A build for one of those four reasons is a decision. A build because the subscription looked expensive is usually a decision to pay more later, in a currency nobody on the team is tracking.

One source, one raw table, one schedule. Resist the urge to write a framework that handles all sources, because the abstraction will be wrong for the second source and disastrous for the fourth.

The mechanics are unremarkable. A single function, invoked on a cadence, is enough for almost every marketing source. Cloud Run functions run your code in response to an event or a request without you managing a server, and Cloud Scheduler provides the managed cron that fires it. That is the entire infrastructure bill for a hand-built connector, and it is close to nothing.

Separate extraction from transformation absolutely. Land the raw response, unmodified, in a table nobody reports from. Every transformation happens downstream, in SQL, where it can be changed without touching authentication code.

Make it safe to run twice before you make it clever, because the recovery procedure for every failure will be to run it again. The property that makes that safe is set out in making a pipeline safe to run twice, and the throttling and chunking side belongs in backfilling without hitting a rate limit.

In practice the portfolio settles into three tiers rather than one choice. Managed transfers handle the largest platforms, since the BigQuery Data Transfer Service automates recurring loads from supported sources on a managed schedule at no licensing cost, and what it does and does not cover is worth reading before you pay anyone for those same sources.

A vendor covers the middle tier, the platforms that are standard enough to be supported and not important enough to own. One or two hand-built connectors cover the sources unique to your clients.

The governance rule that keeps this from sprawling is to count the third tier and cap it. Two hand-built connectors is a maintainable commitment. Nine is a data engineering function you did not budget for, staffed by people with other jobs.

The wider principle is the one Google's cost optimization guidance keeps returning to: the cheapest architecture is the one whose ongoing operational cost you have actually measured rather than assumed. Ingestion strategy belongs in the design phase of a marketing data warehouse build, not in a panic six months later, and it is what made quarterly reporting across more than fifteen clinics hold together without a data engineer on staff.