What the IKEA Business Model Tells Us About Data Platforms
Deconstructing the data platform model with sweet analogies from an IKEA walk
First, suspending assumptions
For most data leaders, the idea of a data platform arrives pre-packaged. It is spoken of as a stack: tools layered neatly on top of each other, or as a purchase decision, something to be evaluated, budgeted, and procured.
These assumptions feel natural because they mirror how enterprise software has been sold for decades. Yet familiarity is precisely what makes them dangerous. When assumptions go unquestioned, they define the limits of what we believe is possible.
A first-principles approach asks us to suspend inherited beliefs and interrogate them at their roots. Is a platform truly a collection of tools, or is that how it is delivered? Is ownership achieved at the moment of purchase, or only when an organisation can shape, extend, and evolve what it has acquired?
The moment we strip away the language of vendors and stacks, a simpler question emerges: what capability does a platform fundamentally exist to create?
The IKEA Moment
On a recent visit to IKEA, somewhere between all the walking and wandering, it clicked: the subtle but powerful analogies between data platforms and IKEA’s remarkably well-designed model, which we’ll get into soon.
IKEA is not in the business of selling furniture. It is in the business of selling optionality. The freedom to assemble, disassemble, customise, outsource effort, change your mind, and scale your ambitions over time. The furniture is merely the visible artefact. The real product is the system that makes all the choices possible.
Seen this way, a platform is the ability to construct, reconstruct, and extend without starting from scratch each time. It is the difference between using something and building with it. The former optimises for consumption, the latter for agency. And agency is what separates tools from platforms.
A Platform Exists to Build Outcomes
What you are offered are Legos, possibilities, and the freedom to assemble them into something that fits your space, not an abstract showroom ideal. The value is in the fact that you can combine them into an outcome that did not exist before you arrived.
Data Developer Platforms, often referred to as DDP, operate on the same principle.
A Data Developer Platform is a Unified Infrastructure Specification to abstract complex and distributed subsystems and offer a consistent outcome-first experience to non-expert end users… (learn more at source)
In analogy to IDP, a DDP is designed to provide data professionals with a set of building blocks that they can use to build data products, services, and data applications more quickly and effectively.
DDP’s existence is credited to teams that want to:
assemble pipelines,
assemble models,
assemble contracts,
assemble semantics, and
Choose when to abstract and when to go low-level
THEMSELVES. Not by filling out tickets or waiting for central teams, but by composing building blocks directly. Consumer-friendly construction. And God knows the countless assets business wants to construct on a daily basis when it comes to data.
This is where tools and platforms diverge. Tools optimise for use and aim to make a specific task easier, faster, and more repeatable.
Platforms optimise for making. They accept that the task itself will change, and that today’s workflow will be tomorrow’s bottleneck.
The highest leverage comes from enabling builders to reconfigure the system as their understanding evolves.
To truly construct, you need
standardised parts that fit together reliably,
clear interfaces that define how those parts interact, and
predictable behaviour when components are composed.
Modularity is Power
Complex systems do not scale by becoming smarter or more sophisticated. They scale by the Descartes’ method: being broken down into units that can stand on their own and still work together. Independence is what allows change to propagate without collapse.
Yet freedom requires strong discipline. When orientation is agreed upon, movement becomes faster. The rule is not there to restrict choice, but to eliminate ambiguity where ambiguity adds no value.
This is why Lego works. Infinite creativity is possible precisely because everyone agrees on the studs, the dimensions, and the orientation. No one debates how pieces connect.
That cognitive load has already been paid. What remains is composition.
Data Developer Platforms rely on the same foundation. Data Operating System, a working implementation of Data Developer Platforms, implements the idea of modularity through composable building blocks or resources:
To own a platform is to accept that constraints must be learned before leverage is earned. Teams must internalise conventions because those conventions are what make independent work compatible at scale.
This is the uncomfortable part of platform ownership: the realisation that freedom is not the absence of rules, but the presence of the right ones.
Platform leverage does not arrive on day one. It arrives after platform literacy.
Ownership is a Gradient
Ownership is often spoken about as a binary state. You either own the platform, or you don’t. You either build everything yourself or you rely on others. This framing is seductive and wrong.
Ownership is a gradient. Not everyone wants, or should want, the same depth of involvement, and forcing responsibility on users is one of the fastest ways to stall adoption.
This board by IKEA is not an apology for their moving parts. It’s an acknowledgement of reality. Some organisations enjoy the act of building structures as their core skill, while others value the outcome more than the process.
A system that respects both is not compromising, but simply expanding reach and wider usability.
A mature Data Developer Platform embodies this same humility.
It supports full DIY for teams that want maximum control and learning.
It offers partial abstraction for those who want speed without surrendering agency.
And it provides full-service assistance when reliability, time, or scale demands it.
Platform maturity is reached when the platform has the ability to meet teams where they are without fracturing the underlying system.
When you decompose an organisation, you inevitably find different personas.
Builders who want to touch every layer.
Accelerators who want leverage without friction.
Delegators who want
internalsoutcomes.
A data platform respects the choice of effort rather than enforcing ideological purity.
The goal of a platform is not to make everyone a builder, but to make the organisation move forward together.
Platforms Optimise for Adaptability Over Perfection
Consider some of the less aesthetic creatures of the world. While we have evolved to think most of them admirable, some still seem a little off course to human senses. But they exist because they survived time, with features that made sense for the benefit of their surrounding ecosystem.
Platforms do not exist to perfect a moment in time, but to survive time itself.
Change is not an edge case to be handled later. It is the default state of any working system. The mistake many organisations make is designing for correctness under static assumptions, only to discover that correctness decays the moment reality moves.
IKEA captures this with disarming honesty: “Because sometimes you change your mind.” This is not a fail-safe mode, but an expectation. The system is designed to efficiently absorb reversals like returns, reconfiguration, and second thoughts without penalty. The cost of being wrong is intentionally kept low.
Data Developer Platforms operate as a defensive system, which means defensible against such reversals. Data products evolve as business meaning shifts. While AI models routinely invalidate yesterday’s carefully curated features and labels. In such an environment, the most dangerous platforms are the ones that make change expensive.
📝. Related Read
This requires a fundamental reframing of governance.
Governance ≠ rigidity
Governance = safe change
Governance does not imply locking things down in the name of control. Governance is the machinery of safe change. It provides guardrails that allow teams to move quickly without tearing the system apart. Cheap reversals → Frequent Experiments/Trials → Progress/Higher Clarity
Scale Requires Services Around Core
No matter how well-designed the core is, scale does not emerge from primitives or building blocks alone. It emerges from the ecosystem that forms around them. This is the uncomfortable truth many platform efforts discover too late: building the core is necessary, but insufficient.
The IKEA information and service point makes way for measurement services, planning help, personal shoppers, delivery, installation… while none of these change the furniture itself. Yet without them, the system would be incomplete and in fact extremely user-averse.
These services reduce uncertainty, compress decision-making, and prevent small obstacles from becoming reasons to stop. Or simply just having the option, even if not taken, brings a sense of peace to users.
Data Developer Platforms require the same surrounding services to function at scale. Ergo, on top of core primitives, DDP enables interfaces: existing system of capabilities to enable quick construction of outcomes instead of mulling over logistics.
Metadata to explain what exists and why.
Observability to understand how systems behave in the real world.
Quality checks to prevent silent decay.
Cost visibility to keep ambition grounded in reality.
AI readiness signals to indicate what can safely be automated and what cannot.
And critically, human support structures that provide context when automation reaches its limits.
Alongside the simpler forms like CLI, GUI, and APIs, as a working implementation of DDPs, Data Operating System unfurls these interfaces on top of its resources:
Platforms shouldn’t attempt to remove humans from the loop. They must be built in a way that human judgment cannot be eliminated, only amplified.
Constraints Enable Business Ambition
Ideas in this world are truly abundant, and business initiatives rarely fail because of a lack of them. They fail because the infrastructure required to carry those ideas exceeds capacity.
Big ideas have significant mass. They need logistics, coordination, and systems that can move them from imagination into reality without collapsing under their own weight.
Business vision often outgrows resource constraints. When teams move:
from projects to data products,
from analytics to AI systems,
from dashboards to chat interfaces,
the nature of the work changes. What once fit inside a single notebook or workflow now demands logistics. This is where platforms earn their relevance.
By absorbing operational burden, enforcing consistency, abstracting through usable interfaces, and providing dependable execution paths, platforms bring velocity to data initiatives. They allow teams to aim higher without paying an exponential tax for reversals, failures, or experiments.
Be it Data Products, Generative AI, Context Graphs, or other shapes and ambitions, a composable data platform surrounded by scalable interfaces offers the stamina to stretch across that last mile without hurting the ones who dared to dream.
Economic First Principle: Pay What You Reap
One of the most misunderstood aspects of platforms is their economics. We are conditioned to think in terms of inventory, like what we buy upfront, what we deploy all at once, and what we must fully commit to before value can be realised.
But that doesn’t work for data platforms that are designed for organisational alignment. Imagine the volume of inventory, including and definitely not limited to resources, interfaces, implementation templates, data products, vertical cross-layer graphs, and so on…
Clearly not the way to go. Pricing shouldn’t resist or obstruct action or curiosity (e.g., experiments), given how a data developer platform is especially a builder’s sanctuary.
The platform must acknowledge that confidence grows with use, that clarity emerges through experience, and that commitment should follow value instead of preceding it.
Data Developer Platforms follow the same economic logic. They allow incremental adoption rather than forced migration. Ownership becomes progressive, deepening as teams internalise the system and expand its use. Value is realised over time, through compounding capability rather than a single, risky bet.
By doing this, platforms reduce commitment anxiety. They make it rational to begin without perfect certainty. And in complex environments, where change is constant and understanding evolves, that may be the most valuable capability of all.
Curtain Call
A Data Developer Platform is not a data stack you deploy.
It is a system that lets you decide how much to build, how much to delegate, how fast to change, and how far to scale, without rewriting the foundation each time.
IKEA taught millions to think in systems. While it might seem easy (as it was meant to be seen), it is an incredible feat. A low-key way of education in systems, modularity, trade-offs, and choice. Over time, millions of people learned how to reason about space, components, constraints, and assembly without ever being taught those words.
This is the shift data leaders now face. The question is no longer which tool to buy or which stack to standardise on. That belongs to an era where problems were smaller, and change was slower. Today, new technology is replacing the old every six months or less. The approach to thought must change too.
The more consequential question is this: what capabilities must the organisation own? Capabilities to build, to adapt, to reverse, to scale, and to decide. Tools may come and go. And platforms endure only when they reshape how an organisation thinks.
*All pictures, unless mentioned otherwise, are taken by the author(s).
Author Connect 🤝🏻
Discuss shared technologies and ideas by connecting with our author(s) or directly dropping us queries and notes on community@moderndata101.com
Find me on LinkedIn 🙌🏻
MD101 Support ☎️
If you have any queries about the piece, feel free to connect with the author(s). Or connect with the MD101 team directly at community@moderndata101.com 🧡
From MD101 team 🧡
🧡 The Catalyst: State of Data Products
Introducing The Catalyst, a special edition of The State of Data Products that compiles insights around the ups and downs in the data and AI arena that fast-tracked change, innovation, and impact.
📘 The Catalyst, first release is our annual wrap-up that compiles the most interesting moments of 2025 in terms of developments in AI & data products, with expert insights from across the industry!
Some focal topics
The gap in AI readiness for enterprises
The shift towards context engineering
Addressing governance debt with a focus on lineage gaps
Revisiting fundamentals for better alignment b/w business vision and AI.
