Buying versus building the analytics layer: the question behind the question

The decision as it usually arrives

A vendor quotes $180,000 a year. An internal estimate says two engineers for nine months, which someone converts to about $400,000 fully loaded, and then adds a maintenance tail nobody can size. The spreadsheet says buy. Eighteen months later the company has the vendor tool, three separate exports feeding a set of spreadsheets that leadership actually reads, and two engineers whose real job is keeping the vendor's semantic model in agreement with the warehouse. The build never happened and the cost showed up anyway.

That pattern is predictable, and it is not caused by picking the wrong vendor. It is caused by comparing a license price against a construction estimate when the two do not measure the same object. A purchased tool and a built layer overlap in what they display and differ almost completely in what they own. The decision starts with separating the parts a vendor can genuinely take off your hands from the parts that stay yours no matter what you sign. The answer, most of the time, is a split rather than a side.

Four layers, not one

"The analytics layer" is a phrase that hides four separable things, each with a different buy-or-build answer. Storage and compute: the warehouse or lakehouse where the data sits. Transformation: the pipeline that turns operational records into analytic tables. Semantics: the definitions that say what a customer is, when revenue is recognized, which rows count as active. Presentation: the charts, dashboards, alerts, and embedded views people look at.

Storage and compute is settled. Nobody should build a query engine in 2026: Snowflake, BigQuery, Databricks, and Redshift are all better than what you would write, and the real decisions there are cost control and data residency. Presentation is settled the same way. Tableau, Power BI, Looker, Sigma, and the embedded analytics products all draw charts well, and competing with them is a bad use of money unless the visualization is your product.

The middle two are where the actual decision lives, and they are the two that vendors are least able to take from you. Transformation encodes how your source systems misbehave. Semantics encodes what your business means by its own words. Both are specific to you in a way no product can anticipate, and both are where the failures that cost real money originate.

The question behind the question

When a director asks whether to buy or build, the thing being decided is almost never the tool. It is who gets to be authoritative about a number. A purchased tool with its own modeling layer is an offer to move that authority into the vendor's format. Sometimes that is a good trade. It is never a neutral one, and it is rarely priced.

The concrete version: your finance team says a customer churned when the contract terminates. Your product team says a customer churned after 60 days of no logins. Both definitions are correct for their purpose. If the semantic model lives in a vendor tool that permits one definition per entity, someone loses, and the losing team quietly builds a shadow model in a spreadsheet. That spreadsheet is now the real analytics layer, and it has no tests, no lineage, and one owner.

So the first question is not "buy or build." It is: can we write down our metric definitions in a form we control, that both the purchased tool and anything we build must read from? Answer that and the rest of the decision gets much smaller.

What a build actually costs, honestly

Build estimates are usually wrong in the same direction, and it helps to know the shape of the error. For a mid-size company with five to ten source systems, a functioning transformation and semantic layer on top of a managed warehouse is roughly 900 to 1,600 engineering hours to first production use. At a blended $160 to $220 an hour for people who have done it before, that lands between $150,000 and $350,000. Internal teams doing it for the first time run 1.6 to 2.5 times that, and most of the overrun is in source-system archaeology rather than in code.

The estimate people forget is the second year. A transformation layer over live source systems is not a project that ends. Schemas change, a Salesforce admin adds a required field, an acquisition brings a sixth billing system. Budget 15 to 25 percent of the initial build annually as steady-state maintenance, and treat any plan that assumes zero as a plan that will produce a quiet outage in month fourteen.

Against that, a purchased platform costs the license plus implementation plus the same maintenance tail, reduced but not eliminated. Vendor implementation at that size commonly runs $60,000 to $200,000 in professional services, and maintenance does not vanish because the vendor's connectors break when the source schema changes too. Compare total four-year cost with a maintenance line on both sides and the gap usually narrows to something far less decisive than the first spreadsheet suggested.

The failure mode that decides most of these

Here is the specific failure that turns a buy decision bad, and it is worth recognizing before you sign rather than after.

The vendor tool models data in its own abstraction. You load your tables, define your joins in their interface, and build dashboards. It works. Nine months in, a business question arrives that the abstraction cannot express: a window function over a slowly changing dimension, a metric that requires a different grain per user role, an allocation rule with an exception for one product line. The tool cannot do it. So an engineer writes a SQL view in the warehouse to precompute the answer and points the tool at that.

That view is the beginning of a second semantic layer. Within a year there are forty of them, they are not tested, half the metric logic is in the vendor tool and half is in views nobody has inventoried, and the two disagree in ways that surface as a number that changed without an explanation. The company now maintains both a purchased layer and a built one, pays for both, and has the reliability of neither.

This is not a hypothetical criticism of any product. It is the arithmetic of expressiveness. Every modeling abstraction has a boundary, and business logic does not respect boundaries. The question to ask on a vendor call is not "can it do X." It is: when it cannot do something, where does that logic go, and who tests it? A vendor whose answer is "you would write a view" has told you that the escape hatch is uninstrumented, which is useful to know before you sign rather than after.

The split that usually wins

The arrangement that holds up over four years, in most companies we look at, is the same shape. Buy the warehouse. Buy the presentation tool. Build the transformation and the semantic layer in version-controlled SQL that lives in your repository, with tests, and make every purchased tool a consumer of it rather than an owner of it.

Mechanically that means dbt or SQLMesh or equivalent producing governed tables and metric definitions, with the BI tool pointed at those tables and as little modeling inside it as you can enforce. The discipline is unglamorous and it is the whole thing. If the BI tool holds business logic, you have two sources of truth. If it holds only presentation, you can replace it in a quarter without renegotiating what a customer is.

What pays for this is portability. BI vendors get acquired, reprice, and change licensing models. A company whose semantics live in its own repository treats that as a procurement event. A company whose semantics live in the vendor's modeling layer treats it as a migration, and migrations of that kind run 6 to 18 months and consume the team that would otherwise be building something.

Layer	Default answer	Why	What breaks if you get it wrong
Storage and compute	Buy	Managed warehouses are better and cheaper than anything you would build	Rarely anything. This is the safe part of the decision
Ingestion and connectors	Buy for common sources, build for odd ones	Fivetran-class tools cover the top 40 SaaS sources well and the long tail badly	An expensive connector for a source with three tables, or a hand-built pipeline for Salesforce
Transformation	Build, in version control	It encodes how your specific source systems misbehave, which no product knows	Logic scattered across vendor UIs with no tests, no review, and no history
Semantics and metrics	Build, own it absolutely	These are your business definitions and they change by negotiation, not by upgrade	Two departments with two numbers and no authoritative way to settle which is right
Presentation and dashboards	Buy	Charting is solved and building it competes with nothing that matters to you	Engineering months spent rebuilding a date picker
Embedded customer-facing analytics	Depends on whether it is the product	If customers pay for the view, it is product engineering and belongs to you	Your differentiating feature capped by someone else's roadmap

When government is in the picture

If any part of the data is federal, or flows to a federal customer, or falls under a contract with security requirements, the buy-or-build calculation changes in ways that are worth being precise about rather than nervous about.

For a system a federal agency operates, the purchased component generally needs a FedRAMP authorization at the impact level of the data, and the sponsoring agency inherits the control set. That constrains the vendor list sharply and, in practice, is the single fastest way to eliminate options. Check the FedRAMP Marketplace before the demo, not after, and check the specific service and impact level rather than the vendor name, because vendors commonly hold an authorization for one product and not the one you want.

For a commercial company handling Controlled Unclassified Information under a federal contract, the governing document is NIST SP 800-171, and the relevant question about any SaaS analytics tool is whether CUI will transit or rest inside it. If it will, that tool is inside your assessment boundary and its controls become your problem. Keeping the analytics layer inside a boundary you already own is often the cheaper answer, not because building is cheap but because expanding an assessment boundary to cover a vendor is expensive and slow.

For systems supporting federal information systems more broadly, NIST SP 800-53 is the control catalog the agency will assess against, and the audit-relevant controls are mostly about access, logging, and integrity of the data pipeline. A built transformation layer in version control satisfies audit questions about change management almost for free. A layer configured through a vendor UI requires you to produce evidence the UI may not keep.

If a model is going to sit on top of it

Analytics layers increasingly feed models, and that changes what the layer has to guarantee. A dashboard tolerates a metric that shifted definition last quarter, because a human reads the chart and remembers. A model does not. It trains on whatever the definition was on the day the training set was extracted, and it serves against whatever the definition is today.

The practical requirement is that the transformation layer produce reproducible snapshots. Not a query with a date range, which returns different rows next month, but an addressable immutable state you can point at and re-derive. Vendor semantic layers rarely give you this, because they are built for interactive queries against current data. It is a normal property of a build in version control with snapshot tables.

If the model influences credit, pricing, eligibility, or anything a regulator examines, the documentation burden runs through the data layer too. SR 11-7 in banking expects the model's inputs to be traceable and the data controls to be evidenced. The NIST AI Risk Management Framework's Map function asks the same questions in more general language. Both are answerable with a version-controlled layer and awkward to answer with configuration inside a purchased tool.

The three questions to ask on the vendor call

Most evaluations run on a feature matrix, which vendors are practiced at winning. Three questions produce more signal than the whole matrix.

Where does logic go when your model cannot express it? Every tool has a boundary. The answer tells you where your uninstrumented second semantic layer will grow.

Can we define metrics outside the tool and have it read them? A yes means the tool is a consumer and you keep portability. A no means the definitions are captive, and you should price the eventual migration into the deal.

What does an export of everything look like on the day we leave? Ask to see the artifact, not to hear it described. Dashboards in a proprietary JSON that no other tool reads are not portable, whatever the contract says about data ownership.

A vendor who answers all three straight is worth buying from. The answers also tell you which parts of the layer you still need to own, which is the output you came for.

What to do in the next two weeks

Before signing anything, write down your ten most-argued-about metrics and the definition each department uses. That exercise takes about a day and it settles the decision more often than a proof of concept does. If the ten definitions are stable and agreed, a purchased modeling layer is a reasonable bet. If four of them are contested, no tool will resolve that, and putting the argument inside a vendor's abstraction converts a business disagreement into a technical one nobody can fix.

Then price four years, not one, with a maintenance line on both sides, and confirm the escape hatch: whether the vendor reads metric definitions from your repository, and what leaving looks like as a file. Those steps cost a week and separate a decision you can defend in year three from one you will spend year three unwinding.

Bottom line

Buy the parts that are solved and commodity: storage, compute, charting, common connectors. Build and own the parts that encode what your business means: transformation and semantics, in version control, with tests. The split is not a compromise between two positions. It is the arrangement that keeps the purchased tools replaceable and the definitions authoritative, which is the property that determines whether the layer is still working in four years. The license price is real and it is the smallest term in the equation.

Frequently asked questions