Gartner predicted that by 2026, 80% of engineering organizations would have an Internal Developer Platform. The prediction undershot: DORA's 2025 research found 90% of organizations reporting use of an IDP, and 76% with dedicated platform teams. Platform engineering is everywhere you look at events like KubeCon and AWS re:Invent, and adoption is no longer the question.
And yet, so many platform engineering initiatives are failing. They're just not taking off. They get stuck in evaluation, unable to get all the different stakeholders on board, and as business cases, they lack the strength needed to get executive buy-in. Or they simply end up in platform engineering hell. The gap between having a platform and having a platform that delivers is now where the whole game is played. DORA's own finding is that when platform quality is high, AI adoption has a strong positive effect on organizational performance, and when platform quality is low, that effect is negligible.
The reality is that the majority of teams don't have the know-how to design, build, and roll out a platform successfully.
Interestingly, most people reading the above will immediately think the choice of the tooling stack or the technical design would be the main challenge. But that's not true. Platform initiatives almost never fail because of technical reasons e.g. you picked this tool over that other one. Plus, there are established blueprints like the reference architectures (see examples for GCP, AWS or Azure) to help guide you in your tooling decisions.
Platform rollouts fail because of two things teams get wrong: culture and process.
We spoke about cultural failures before. Reasons include:
- You can't speak C-level lingo to get exec support.
- You don't listen to devs who want a platform that doesn't abstract too much.
- You don't figure out the right separation of concerns between platform teams and existing infra ones. A written shared responsibility model - platform team owns the paths, control functions own the rules, infrastructure teams own the environment - is what that separation looks like when it works.
But the more I speak to platform engineering teams, the more I realize these cultural aspects are not even the primary culprits. The real project killers are process and speed (or lack thereof).
Stop procrastinating: Think Minimum Viable Platform (MVP) first
The problem is that most platform teams simply don't have the right processes (and often the expertise) to:
- Understand how their users actually work today, before deciding what to build.
- Get key stakeholders on board with the initiative. And…
- Prove value quickly enough to said stakeholders so their initiative doesn't lose momentum.
If you spend 12 months designing your platform to try and accommodate every possible use case and make everyone happy at the same time, you will fail. Guaranteed.
In our recent book, Thinking in Platforms we explain the case of a US-based insurance company that starts with a wildly large mandate, lofty dreams and the concept of a platform that can achieve everything at once. This is the ultimate setup for failure; the MVP is your rescue.
Instead, what you need to do is start from your users and work outwards. Paths are discovered from observation, not invented in isolation, so this begins with discovery: run discovery interviews with the teams doing the work, deep dive on how a piece of recurring work actually moves today, map the value stream, and write down the path candidates that come out of it. Then force-rank them. You are looking for one recurring intent, done often enough and painfully enough that fixing it is obviously worth something.
Only then does the stakeholder question come in. Identify who the key stakeholders are that will allow you to get the initiative off the ground by showing them value fast. Depending on your org structure these can be your architects, C-level, or app dev leadership. The point here is you don't need to please every possible dev team in your org or all your security teams, plus your entire technical leadership at the same time to win.
Pick the right battles to fight, in the right order. Carefully select your internal champions and prove your platform initiative will deliver the highest ROI your company can achieve right now. Frame that ROI as the cost of chaos you are removing: what the current way of working costs across delivery velocity, outcome predictability, operational resiliency, maintenance overhead, organizational learning, and structural incentives.
The way you do this is by shipping an MVP in weeks, instead of months or years. Find a pioneering team to build it for. Get the key stakeholders excited, get feedback, and find more pioneers and sponsors. And before you know it you'll have built real momentum across your entire engineering org to really get this done the right way.
How you get to your Minimum Viable Platform
The concept of an MVP (as in Minimum Viable Product) is of course very established and rooted in the lean methodology of launching with just the essentials to prove your concept. A Minimum Viable Platform borrows the discipline and changes the unit. And the approach has moved from community practice to research-backed guidance: DORA now recommends it by name, advising organizations to identify the golden path for the most common workflow and build just enough to make that specific journey demonstrably better.
Manuel Pais, co-author of Team Topologies, has been talking about the Platform as a Product approach for years now and on your YouTube channel, you can find tons of talks about product strategies for your platform.
But let's get more pragmatic. How do we define a Minimum Viable Platform? One golden path, for one persona, end to end. That is the whole scope. Pick the highest-ranked path candidate from discovery and make it work properly for a single group of users - including the resources it consumes, the interface it is invoked through, and the definition of done it has to satisfy.
A useful way to build it is against a simple HelloWorld app, one that has as much in common as possible with your real apps but without all the custom and often unnecessarily complicated edge cases, using the common infrastructure your apps normally consume. Just keep the distinction straight: the HelloWorld app is the test subject, the path is the deliverable. A stack that provisions is not yet a platform. A repeatable route from user intent to usable output is.
[GRAPHIC: existing MVP diagram from the live piece - needs redrawing to show one path end to end (intent, interface, capabilities, output) rather than a stack of resources]
Keep in mind the M stands for minimum. This means you want to ensure the following is always true about your MVP:
- Representative: The MVP should cover a path that recurs across the technical estate, running on representative basic resources and components. Generally, this includes clusters, containers, version control, a single database type, basic DNS, and basic CI/CD.
- Repeatable: The skeleton created in the MVP process should be able to be used as a "quick start" for other applications and teams within an organization. The MVP is the foundation from which the full-scale platform is built.
- Iterative: MVPs are focused on the future. The context of creating this version of the platform is with growth and iteration in mind. Remember that commitment is required to scale.
- Innovative: The teams that work on these MVPs are pioneers and drive new ideas forward. MVPs should provide inspiration for contributors to learn new things and engage with new technologies.
You should also always keep in mind what you should NOT optimize in your MVP phase:
- High-compliance scenarios: You can think about security and high-compliance requirements, but an MVP does not need to serve your most regulated workloads. What you should not defer is identity, policy, and state - the three layers that make a platform enterprise-grade. Keep them thin, but keep them in, and keep policy embedded in the path rather than bolted on as an approval step afterwards.
- Advanced architectures: Service meshes, multi-cluster deployments, failover, customized portal integrations, advanced CI/CD (Blue/Green) etc. do not need to be covered by an MVP.
- Advanced resource configuration: You should pick one common resource type to begin with and not try to cover every possible developer request.
- Advanced observability: Integration of advanced components and highly complex observability services is something you can build on top later.
Getting the degrees of freedom right
Once you follow these principles and ensure you're building an MVP, the next thing to focus on is how much variability your path exposes. This is a product decision, not a technical one, and it has three positions.
Rigid paths are intentionally narrow, because variance introduces risk. Controlled paths are flexible within validated boundaries. Golden paths expose rich configuration options but ship with defaults so well chosen that users rarely deviate - and when the path does not fit a particular situation, users can still step off it. For an MVP, golden is almost always the right answer.
Get this wrong in either direction and the MVP stalls. If you don't absorb enough complexity on behalf of developers, you haven't built a platform. At the same time, if you remove too much context, devs will push back on you. Listen to them, follow a Platform as a Product approach, and iterate.
Many platform teams also confuse abstraction with just offering a developer portal UI. That's the nice front door on a non-existent house. The interface is where user intent crosses into the platform but it is not the platform itself. Developers tend to respond much better to code-first interfaces.
Finally, set yourself an ambitious goal and aim to show value to all key stakeholders within two weeks. Decide up front how you will show it: DORA metrics for delivery outcomes, SPACE metrics for the experience dimension, and Platform NPS for whether your pioneering team actually wants to keep using what you built. DORA's own guidance here is a balanced scorecard with delivery performance on one side, developer satisfaction and adoption on the other because platforms can improve productivity while temporarily denting throughput and stability if measured on delivery alone. "It works" is not evidence.
This might sound too ambitious, but I've seen it happen many times in teams that have followed all of the above.
Next steps: from MVP to scale
After two weeks, you'll have a Minimum Viable Platform that:
- Proves to you and everyone else that matters, that this is the best thing you should be investing in. And…
- is ready to grow to the next phase. This is the foundation upon which your full-scale platform will be built, fostering a culture of innovation and continuous development.
Now go use this MVP to get buy-in from your selected pioneering group. The group of stakeholders that will become your lighthouse team in the organization (think the same people that first adopted Kubernetes, Terraform, etc.)
Gather their feedback and iterate. From here the work has two named stages, and skipping either is how promising MVPs die. A Production Readiness Program takes the MVP path from working to trustworthy: the compliance, identity, policy, and state requirements you deliberately kept thin now get built out properly. A Platform Scaling Program then takes it from one team to many, driven by an onboarding loop which defines and structures how to onboard a team, watch where the path breaks for them, fix it, onboard the next. Adoption is earned this way, one team at a time, not mandated by an announcement.
The whole procedure is what we refer to as the Platform Engineering Playbook that we’re describing in part 3 of our book..
MVPs in the age of AI agents
There is a question the original version of this article did not have to ask: who are the users of the path you just built? If the honest answer includes agents, the MVP needs to account for it, because agents multiply whatever already exists. In an artisanal or hero-based production system they multiply chaos. In a platform-based one they multiply throughput.
AI is an amplifier that magnifies an organization's existing strengths and its dysfunctions, individual AI productivity gains are routinely lost to downstream disorder, and platform quality is the variable that decides whether AI adoption translates into organizational performance at all. The platform is the distribution and governance layer for AI. Whether yours is good enough is now the difference between AI investment that compounds and AI investment that evaporates.
That does not mean building agent infrastructure into a two-week MVP. It means knowing that an ambiguous path a human muddles through is a path an agent will run a thousand times a day and fail a thousand times, and that the platform you scale to is increasingly an Agentic Development Platform, rather than an IDP for humans only. The MVP approach is unchanged. The end state moved.
Whether your platform delivers is a different question, and it's decided by process, not tooling. To dive deeper into the strategies and frameworks for building a successful Minimum Viable Platform, check out our new book, Thinking in Platforms. You can also join the Platform Engineering Slack to exchange best practices with other practitioners and sign up for PlatformCon to learn from leaders in the space.
Note: The first version of this blog post was published on 1 March 2024 and it was last updated on 21 August 2026.
