“Build vs. buy” is really just “buy vs. buy”

Every time we sit down with a new prospect, someone on the team says a version of the same sentence: "We've already built it ourselves."

The instinct is to take that at face value and move on. However, as we discovered, our sense of what it means to build a marketing reporting system and the customer's sense of it are, almost always, two different things. So we ask a follow-up question: what did you actually build? And very rarely does anyone say they built their own ETL pipelines.

There's a reason for that. Maintaining ETL pipelines into Meta, Google, TikTok and a dozen other ad platforms is low-value, high-maintenance work. The APIs go through regular version upgrades, and none of it is a one-time build. Most teams decide, reasonably, that this isn't where their best engineering hours should go. That's the entire reason Fivetran exists: to take a tedious, non-strategic problem off your plate.

So if it's not the ETL, what did they build? Push a bit further and you find the same thing. Almost no one has built their own database. Hardly anyone is hand-coding a BI platform with version control and proper semantic layers. What you find instead is a familiar stack: an ETL tool like Fivetran, a warehouse like Snowflake or Databricks, dbt Cloud sitting on top to manage transformations and schema, and a dashboarding layer like Looker, Tableau or Omni on top of that. Four vendors, all charging on some flavor of compute or rows ingested. What actually got built is the glue that keeps those four things talking to each other.

That's not a criticism, it's just a more accurate description. "We built our own reporting" usually means "we bought three or four solutions built for data in general, and stitched them together ourselves." These general-purpose data tools were never purpose-built for performance marketing data, which is why there's so much curation and glue work left for your team to do in the first place.

The build itself isn't the hard part

Getting a warehouse up with a first version of a dashboard is now fairly quick. Where it gets hard is everything after that. Business stakeholders don't stop asking questions once the first dashboard is built. They will ask for a new metric, a new dimension, a new slice of the data. First, campaign level reporting became insufficient, then ad-level reporting - asset-level reporting is the game now. Through all these changes, someone has to decide what happens to the historical data, how to reconcile the old definition with the new one, and how to explain to a marketer why last quarter's numbers don't line up with this quarter's the same way anymore. It's ongoing, it's tedious, and it is very hard to keep up with.

This is the last mile of reporting, and it's where things get real. No one is querying Snowflake directly to make a budget call, no one is looking at the raw ETL output and deciding where to shift spend. People work with dashboards that were built for them, and every one of those dashboards is now a piece of standing maintenance. We've heard from teams with literally a thousand Looker dashboards built up over the years and nobody left who knows who's using which one, so nobody wants to be the one who breaks something by pulling access.

Someone might reasonably point out that AI and code assistants have made building and maintaining ETL a lot easier than it used to be, and that's probably true. But even if the pipeline maintains itself, the last mile doesn't go away because the people who build the ETL and the people who use the reports are different people. Marketers who need a new metric will file a ticket with a data team that has its own priorities and doesn't share the same urgency around schema changes. That gap creates a dependency, and a dependency creates lag. Making the pipeline cheaper to build does nothing to close it.

Ask a data team what the most frustrating part of their job is, and the answer is usually QA. There's a useful parallel to on-call rotations in software engineering: on-call work is unpredictable, high-pressure, and never strategic. Nobody gets promoted for the number of tickets they closed or the number of dashboards they kept alive, they get promoted for the projects they shipped. And yet marketing reporting, more than almost any other function, generates exactly this kind of work: reactive, unglamorous, and endless.

Why does this happen in the first place?

Let's take the building claim at face value for a second: what's the actual build-vs-buy calculus here? There are, in practice, three considerations.

The first is strategy: is this something so core to how your business competes that building it yourself creates a genuine advantage? The second is cost: over a multi-year horizon, is doing it yourself actually cheaper, once you count engineering time and compute? The third is governance: do you need a central source of truth that the whole business trusts, rather than everyone building their own version of the numbers?

Marketing reporting rarely clears the first test. Competent marketing reporting looks remarkably similar across companies. The bulk of the problem is mechanical: importing, storing, and transforming third-party ad platform data frequently enough, and at the right level of granularity. The part that requires real company-specific thinking - what you measure, and how - is a business logic question about your industry and stage, not a tooling question. It has almost nothing to do with which warehouse you picked or how well the pieces are glued together.

The cost calculus is worse than it looks, too. Code may have gotten cheaper to write, but compute hasn't gotten cheaper to run. Warehouses like Snowflake, Databricks and BigQuery charge by volume, so nearly every team we talk to stops at campaign-level data, because there's little ROI justification for ingesting three more layers of granularity when you're paying by the row. But marketers need keyword-level, ad-group-level, asset-level, product-feed-level reporting, because the old signals disappeared along with third-party cookies and platform-level attribution, and the only way to understand what's actually working now is to go granular.

Governance is the one argument that holds up on its own terms, and it deserves to be taken seriously rather than waved away. The instinct behind it is legitimate: you don't want every team building its own reports and its own version of the truth, and you want the people making decisions to at least be looking at the same numbers. But the assumption underneath that instinct - that decisions are being made inside the BI dashboard - usually doesn't survive contact with how marketers work. BI dashboards are where questions arise but can't be answered. Someone looks at a dashboard, notices something off, and leaves to go figure out why - usually back into the ad platforms themselves, working from partial, single-channel data, or into a spreadsheet, which is a data governance nightmare in its own right. You lose any network effect of people learning from each other's data. You cannot force people back to a governed system that doesn't actually answer their question. So the concern behind governance is valid, but the fix isn't more centralization, it's making the self-service layer good enough that people never have reason to leave it.

What building well would actually require

Put all three together and marketing reporting sits squarely in the buy bucket. Gluing four vendors together doesn't buy you additional insight - it buys you reporting that looks like everyone else's, plus the ongoing work of keeping it stitched together. The actual competitive advantage comes from getting granular, near-real-time reporting into a marketer's hands as fast as possible, in a way that doesn't degrade as the business changes.

That's the case for a single, purpose-built full-stack tool over a stitched-together one: nothing to glue, nothing to maintain, and it's a system that was designed around performance marketing data rather than data in general. It's a big part of why we built Clarisights in the first place - there was no good way to get this right by everyone building it from scratch, and no good way to get it right by buying four things and connecting them together.

Want to see what a reporting stack designed for exactly this problem looks like? Book a demo and we'll be happy to show you.