Your Data Platform Needs About 15 Customers Before It Pays for Itself

The break-even math, the Fabric capacity trap and the operating model behind an enterprise data and AI platform, with the working Python on Substack.

Most enterprises do not have a data platform. They have a pile of projects that each built a slice of one: three ingestion tools, two model registries, a lakehouse nobody owns and a GenAI pilot in a forgotten subscription. Each slice had a business case. Together they produce duplicate pipelines, conflicting numbers and spend nobody can explain.

The fix is to run the platform as a product, with an owner, a published service level and a cost line for every service. I wrote a full deep dive on how that works on Azure, Microsoft Fabric and Microsoft Foundry, including the operating model for a team of 20 to 25 and runnable code for every control. This piece gives you the core ideas. The implementations live on Substack.

The break-even nobody computes

A shared platform service pays for itself only when enough teams use it. The proposed planning model is n* = F / (b − m): the annual fixed cost of the service divided by what each team saves by not building its own.

Worked in engineering hours, a governed ingestion service costing 1,200 hours a year to build and run, replacing pipelines that cost each team 100 hours a year, with 15.3 hours of onboarding and support per consumer, breaks even at 14.2 consumers. At 25 consumers it saves about 917 hours a year. Below 15, it loses.

That one number changes roadmap conversations. Ingestion, identity and model serving clear the bar easily in a large company. A niche feature store for one analytics team does not. The full article covers how to use the number to pick what to build, and what to retire.

Reliability as a budget

An SLO of 99.5% over 30 days leaves an error budget of 3.6 hours. Alerting should fire on how fast that budget burns, not on single failures: the Google SRE Workbook’s multi-window method pages when both a 1-hour and a 5-minute window burn at 14.4 times the allowed rate, which spends 2% of a month’s budget in an hour.

The budget also sets policy. When a service spends it, feature work pauses until reliability recovers, and that rule is agreed with consumers before the first incident. The full article includes the burn-rate alerting code and the lifecycle gates from incubation to retirement.

The Fabric capacity trap

Fabric bills compute as one pool of capacity units shared by every workload. It smooths background jobs over 24 hours but interactive work over only 5 to 64 minutes, so a heavy nightly load can surface the next morning as rejected executive dashboards.

A simple sizing model adds smoothed background load to peak interactive load. In the worked example, 2,900,000 CU-seconds of nightly work plus a busy 5-minute window comes to 53.6 CU, about 84% of an F64. At compiled US list prices of about $0.18 per CU-hour, that F64 costs $8,409.60 a month pay-as-you-go, and simply pausing an F8 dev capacity outside working hours cuts it from $1,051.20 to $316.80. The full article includes the chargeback code, including how to charge for idle capacity so whoever picks the SKU has a reason to right-size it.

Governance and partners, measured

Controls that teams must remember get skipped. Controls built into templates and pipelines run every time. The article walks through deployment as code with Microsoft’s fabric-cicd library, data contracts that stop a load when volume drops (a z-score of −4.2 in the example), and a policy check that blocks any AI release missing an evaluation run, a guardrail policy or an impact assessment.

The same discipline applies to managed service providers. Score them on outcomes from your own telemetry, and score availability as a failure rate: a partner at 0.9% failures against an allowed 0.5% has used nearly twice its budget, but a naive ratio of 99.1% to 99.5% would score them 0.996.

What’s in the Full Article

• A team topology for 24 people across five service-aligned teams, and why it cuts communication paths from 276 to 62
• Burn-rate alerting, data-contract and chargeback code you can run today
• A Fabric capacity sizing model with throttling stages explained
• A CI/CD deployment script for Fabric and an AI release policy check
• What changes for engineering, construction and other asset-intensive firms

Written for data and AI platform leaders and the senior engineers who build with them.

Read the full deep dive on Substack → https://brianjamescurry.substack.com/p/the-platform-is-the-product-running

Subscribe on Substack for the next two pieces in the series, on GenAI evaluation and production agents.

About the Author

Brian Curry is a Kansas City-based machine learning and AI strategist, marketing economist, and applied researcher. He leads Vector1, an independent research studio working on cognitive AI, causal inference, marketing economics, and knowledge engineering, with a focus on simulation-driven intelligence systems.

Over more than twenty years, Brian has led data science and analytics initiatives at enterprises ranging from $4B to $125B in revenue, including Koch Industries, Tractor Supply, Vail Resorts, Hallmark, Garmin, and AT&T. His work applies economics and causal inference to connect marketing investment to structural outcomes, operational decisions to economic value, and AI adoption to durable competitive advantage.

He is also the founder of KC AI Lab, a 1,500-member AI and ML education community in the Midwest. He lives in Kansas City and is an active part of the Kansas City community.

Research and Open-Source Projects

The modeling approach in this paper draws on PyCausalSim and Papilon.

Causal Inference and Economics

• PyCausalSim: Simulation-driven causal discovery and evaluation, using counterfactual scenarios to isolate structural drivers.
• Papilon: Complex-system simulation and optimization, with applications in media mix modeling and adaptive architectures.
• Daedalus: Causal analytics for money-flow mapping and macroeconomic tracking.
• The Autonomy Economy: A macroeconomic framework for the combined effects of rapid productivity growth and structural price deflation in an AI-automated economy.

Forecasting and Applied Modeling

• Regimecast: Time-series regime detection, structural breaks, and economic forecasting.
• CarryNet: Financial modeling for commodity carry trade analysis.
• Foodmesh-ml: Machine learning, optimization, and simulation for distributed food systems.

Cognitive AI and Semantic Architecture

• Memory-Node Encapsulation (MNE): A cognitive AI architecture and data structure for artificial episodic memory (NeoCortex-M).
• MeaningFlow: Semantic content modeling, embeddings, clustering, and coverage gap analysis.

Contact: brian@vector1.ai | GitHub @Bodhi8 | Substack

The text of this article may be shared with attribution under Creative Commons Attribution 4.0 International (CC BY 4.0). Code and models referenced here are available separately to paid subscribers.