Rent the Lake, Own the Definitions

What you are actually deciding

The build-versus-buy conversation about data platforms is usually framed as cost. It is really about calendar and staffing, and the honest version of the question is narrower than the one that gets debated.

Nobody at mid-market is building storage, compute, or a query engine. That decision was made for you by Snowflake, BigQuery, and Databricks. What is genuinely in play is the layer above: ingestion, orchestration, monitoring, governance, and delivery.

Building that layer is six to nine months and one to three permanent engineers. Renting it is days to weeks and a subscription. The interesting part is which pieces you should never rent, and there is one.

Layer by layer

Storage and compute: buy. Not a real decision. Pick the one next to your existing cloud.

Ingestion: buy for standard sources, build for your weird one. Nobody should write a Shopify connector. Somebody has to write the connector for your 2011 WMS, because no vendor sells it.

Orchestration: buy. Scheduling, retries, dependency graphs, alerting on failure. Well-trodden and boring, which is exactly what should be rented.

Governance and access: buy. Row-level policies, audit logging, credential handling. This is the layer where a homegrown version fails an audit two years in.

The semantic layer: build. Always. Your metric definitions, fiscal calendar, store hierarchy, and SKU tiering are your business logic. No vendor can write them and no vendor should own them.

Delivery: buy or build depending on where your people already work. If district managers live in email and a mobile app, buy something that reaches them there. Building a portal nobody opens is the most common way to waste the last mile.

The failure pattern runs opposite to this list. Teams build orchestration and governance, because those feel like engineering, and skip the semantic layer, because it feels like documentation. Eighteen months later they own a scheduler and still cannot answer what margin was last week.

Four questions that settle it

Can you hire and keep two data engineers? Not can you get two requisitions approved. Can you keep them for three years. Median tenure in mid-market retail data roles runs under two years, and a platform built by someone who left is a platform in maintenance mode with nobody who understands it.

Is any part of your pipeline a competitive advantage? Almost never. Your assortment logic might be. Your ingestion of a NetSuite table is not. Build where the advantage is and rent everything else.

What happens on the Saturday a feed breaks? Owned platforms need an on-call rotation. If the honest answer is that it waits until Monday and the district managers get a stale number, you have chosen a service level, and it should be a deliberate choice rather than a discovery.

What is the cost of the months? Build is six to nine months to first answer. Rent is days to weeks. Price the difference in decisions made without the information, not just in salaries.

The one thing never to hand over

Metric definitions. Not the tooling that stores them. The definitions themselves.

What counts in net sales. Whether margin uses landed or standard cost. When a fiscal week starts. Whether a store that remodeled in March is comparable. Whether an online order fulfilled from a store counts to that store.

Those answers are your business, they differ from your competitor's, and they are the reason two retailers running identical software report different numbers. A vendor can host them. A vendor cannot write them, and every deployment that lets a vendor guess produces numbers that are close enough to look right and wrong enough to lose trust in month four.

Practically: keep the definitions in a document you own, in plain language, versioned, with a named owner per metric. Whatever platform renders them should read from that, and you should be able to walk out with it.

Lock-in, priced honestly

Lock-in is real and it is smaller than it is used to argue with.

Your raw data stays yours in your own storage under any sane arrangement. Confirm that in writing before signing: raw landed data in an account you control, in an open format, with no export fee.

What you would rebuild on exit is the transformation and monitoring configuration. For a mid-market retail deployment that is weeks of work, not quarters, provided you kept your definitions in a document rather than inside the vendor's UI.

Weigh that against the lock-in of a built platform, which is a single engineer who understands the whole thing. That dependency has no contract term, no exit clause, and no notice period.

The cost shape

Build, mid-market retail: two engineers fully loaded at $300,000 to $400,000 a year, plus platform spend of $30,000 to $120,000, plus tooling. Call it $400,000 to $550,000 annually, with the first answer arriving somewhere in month six to nine.

Rent: platform spend plus a subscription, typically $60,000 to $200,000 annually at this scale, with a fraction of one internal person owning the relationship and the definitions. First answer in days to weeks.

The build number is not wrong for everyone. Above roughly $1B in revenue, with a real data organization and use cases that need custom modeling, owning the layer is defensible. Below that, the two engineers spend most of their time on connector maintenance and pipeline babysitting, which is generic work that a vendor does across many customers at lower unit cost.

The default

Rent the plumbing. Own the definitions. Start read-only. Judge on time to first trusted answer, not on feature count.

The version of this that fails is the one where a retailer rents a platform, never writes the definitions, and expects the vendor's defaults to match a business with a 4-5-4 calendar and 30 remodeled stores. The plumbing was never the hard part. It was just the part that took nine months when you built it yourself.