Build or buy your data platform.

Build versus buy gets argued as one question and it is five. A data platform is a stack of layers that happen to be sold together, and the right answer is different at each layer. Organisations that argue it as a single decision tend to buy a suite they only half use, or build something they cannot staff.

Here are the five layers, what we would do at each, and the cost model that settles the cases in between.

Layer 1: storage and compute. Buy.

The engine that stores the data and runs queries against it. Snowflake, Databricks, BigQuery, Microsoft Fabric, or a managed Postgres if your volumes are smaller than you think.

Nobody should be building this. The interesting question is not whether to buy but which commercial model you are buying into, because they price differently under load. Consumption pricing is cheap while usage is exploratory and unpredictable once a platform is genuinely in production, which is exactly backwards from how most business cases model it. Get a supplier to model your second year, not your first.

The other decision hiding here is region. If your data cannot leave Australia, that constrains which services and which features are available to you, and it constrains them per service rather than per vendor. We have set out how that works in where your AI data can live.

Layer 2: ingestion. Buy, with one exception.

Connectors that pull data out of source systems. Fivetran, Airbyte, Stitch, or whatever your platform vendor bundles.

Engineers routinely build these, because any single connector is a fortnight's work and looks like an obvious saving. The cost is not the fortnight. It is that the source API changes, the schema drifts, the incremental logic has an edge case at month end, and the person who wrote it has moved teams. A portfolio of thirty hand-built connectors is a permanent maintenance obligation that nobody agreed to take on.

The exception is the system with no commercial connector, which in Australian organisations is commonly a local industry package, a state government data feed, or a bespoke system written in-house fifteen years ago. Build those, deliberately, and put their maintenance in someone's job description rather than leaving it in a project.

Layer 3: transformation and semantics. Build.

This is the layer that encodes how your business works: what counts as an active customer, how revenue is recognised, which adjustments apply to which region, what the fiscal calendar does.

No vendor can supply this, because it is not a technology, it is your organisation's accumulated agreements written down. Vendors sell accelerators and industry models that claim to, and they are useful as a starting structure, but the moment your definitions differ from the template you are maintaining someone else's model plus your exceptions, which is worse than maintaining your own.

Build it in a tool everyone else uses, with tests and version control, rather than in a proprietary modelling layer that only exists inside one BI product. The logic has to outlive the tool. This layer is also where governance actually lives, which is the argument in why AI needs a governed data platform.

Layer 4: orchestration and observability. Buy.

Scheduling, dependency management, retries, alerting, lineage, freshness monitoring.

Cron plus a Slack webhook is the classic build here, and it works until the first quiet failure. Quiet failure is the expensive kind: a pipeline that succeeds while loading yesterday's file again, for three weeks, into a dashboard someone is making decisions on. Buying observability is buying the ability to detect that, and it is the layer whose absence costs the most and shows up the latest.

Layer 5: consumption. Buy, and expect to buy more than one.

Dashboards, notebooks, embedded analytics, the interfaces AI systems query. Power BI, Tableau, Looker, plus whatever your applications need.

Organisations spend a surprising amount of effort trying to standardise on one, on the grounds that multiple tools is a governance failure. It is not, as long as they all read from the same semantic layer. Two tools reading one set of definitions is fine. One tool with definitions rebuilt inside it by four teams is the actual failure, and it is common.

The cost model that settles the rest.

When a layer is genuinely marginal, the thing that decides it is not licence cost against build cost. It is run cost.

A bought platform costs roughly its licence fee plus a small operating overhead. A built platform costs, in our experience across Australian mid-market deployments, 40% to 60% of its original build cost every year thereafter, and that cost is people: upgrades, connector repair, on-call, and the institutional knowledge that walks out when an engineer resigns. A business case that compares a three-year licence against a one-off build has compared the wrong two numbers.

Two further asymmetries matter. A bought platform's cost is visible and negotiable at renewal. A built platform's cost is invisible, because it is distributed across salaries, which means it never triggers the review that would surface it. And a built platform concentrates risk in a small number of people, which in a data team of six is a genuine operational exposure rather than a theoretical one.

When building actually wins.

Three cases, and they are narrower than they are usually claimed to be.

• The platform is the product. If you sell data or analytics to your customers, the platform is revenue-generating engineering and should be treated as such.
• You are outside the commercial envelope. Genuinely high volume, genuinely low latency, or a workload shape that consumption pricing punishes. This is real, and it is rarer than the number of organisations that believe it applies to them.
• Residency or sovereignty excludes the managed options. Certain classified government workloads and some regulated data classes cannot use a managed service with cross-border support access. That is a legal constraint and it decides the question.

"We are unique" is not one of the three. Most organisations are unique in their layer 3 definitions and ordinary in layers 1, 2, 4 and 5, which is exactly why the split above holds.

A practical sequence.

Buy the engine. Buy the connectors for every source that has one. Build the transformation and semantic layer yourself, in a portable tool, with tests. Buy the orchestration before you need it rather than after the first quiet failure. Let consumption tools proliferate as long as they read from the one semantic layer.

Then put a run-cost line in the business case, three years long, for whatever you decided to build. If nobody will sign it, you have your answer about that layer. More on how we approach the whole stack is on modern data infrastructure.

General information only, not legal or regulatory advice. Current as at September 2026.