Max Körbächer, founder and technology advisor at Liquid Reply and author of Platform Engineering for Architects, argues that an internal platform does not succeed because its technology is impressive. It succeeds when it addresses real needs, fits the organization, and earns continued use.
These are learning notes from his presentation at InfoQ Dev Summit Munich 2025, which InfoQ published with a transcript on July 20, 2026. Sections labelled Presentation Notes report Körbächer's argument and examples; numerical results are his anecdotal reports, not independently verified benchmarks. The final Synthesis section contains my interpretation rather than claims made directly in the talk.
Presentation Notes: Why Platforms Fail
Körbächer identifies several recurring failure modes:
- The platform has no defined purpose or desired outcome.
- Management expectations do not match what the platform delivers.
- Builders do not understand or measure user needs.
- The design is over-engineered around attractive tools rather than common problems.
- Adoption is expected through mandate instead of earned through usefulness.
- Technical debt accumulates without explicit retirement criteria.
He calls tool selection without a validated problem "randomeering": adding a technology because an engineer encountered and liked it. His Backstage example illustrates the broader issue. Installing a portal can produce an impressive but empty interface; in his estimate, reaching a useful first extension can take five engineers a couple of months. The criticism is not that a particular portal can never work, but that deploying one is not the same as creating a platform product.
The deepest failure mode is infrastructure-first thinking. Many platform teams originate in infrastructure or operations, so they naturally begin with architecture and tools. That reverses product discovery: it supplies a solution before establishing whose problem it solves.
The demand for a platform does, however, have a real organizational source. As CI/CD, observability, security, and compliance responsibilities shift left, separate application teams often implement and operate the same capabilities independently. Reorganizations and technology hype can repeatedly break attempts at standardization, leaving duplicated operations, release management, user management, and internal communication. Körbächer presents platform engineering as a way to turn that recurring patchwork into a shared product, not as another name for the same operations team.
Presentation Notes: What the Platform Is For
Körbächer rejects the framing of a platform as a finite project. A project ends at a deadline; a product must keep adapting to users, dependencies, and organizational change.
The platform's customers can include more than application developers. Security specialists, compliance staff, product owners, and business leaders may all consume platform capabilities or information. He describes one platform where almost half of the vice presidents viewed a weekly GitHub-hosted report on usage and deployments. It had no elaborate front end, but it delivered information in a workflow those users could access.
His practical distinction is blunt: a platform without adoption is infrastructure. Adoption here means that people happily use the capabilities, not merely that accounts exist or management requires compliance.
Before implementation, the team should state a purpose that answers:
- Which people and roles does the platform serve?
- What are their goals and values?
- What business or user value should change?
- What principles will guide decisions?
- Which stakeholders, strengths, and development gaps matter?
- Which indicators could show whether the purpose is being fulfilled?
Körbächer distinguishes purpose from a fixed vision or mission: it is the reason the platform should exist, and it can change as circumstances change.
Presentation Notes: Desirability, Viability, and Feasibility
The talk reframes the familiar iron triangle around three questions:
| Dimension | Question |
|---|---|
| Feasibility | Can we build the thing right? |
| Desirability | Are we building something the customer wants? |
| Viability | Are we building the right thing for the organization? |
Time, staffing, and budget prevent small teams from maximizing all three immediately. Körbächer therefore recommends a thinnest viable platform: begin with one or two capabilities that solve verified problems, then add features in response to evidence. This limits speculative scope and reduces the amount of technology that can become debt before it proves useful.
Principles provide a decision framework when requests and drivers conflict. He suggests combining:
- "We will" principles that build team unity, such as making resource consumption transparent.
- "You must" principles that guide consumers toward necessary practices without prescribing every implementation detail.
Other example principles are to focus on common problems and eliminate waste. Körbächer says his former FinOps team reduced cloud costs by 50% at every company it entered. That is a broad, speaker-reported consultancy claim without sample size or methodology; its role in the talk is to argue that economic outcomes belong in platform decisions, not to establish a general benchmark.
He also separates four sources of direction: strategic demands from leadership or partnerships, personal and ethical motivations, market changes such as licensing or sovereignty requirements, and analyst or industry reports. Naming the driver makes it easier to distinguish a user problem from an externally imposed constraint.
Presentation Notes: Research Workflows, Not Tool Requests
Product mindset requires direct user research. Körbächer proposes five starting questions:
- What tools do you use now?
- What does the current workflow look like?
- What migration effort would a change require?
- Where are the current gaps?
- What would the ideal workflow look like?
These questions investigate work and friction rather than asking users to design the platform. They also expose adoption cost. A technically superior capability can still be a poor product decision if migration interrupts too much work or requires users to abandon established workflows without enough benefit.
Feedback must be continuous and specific. An annual company survey asking whether employees like their tools produces a momentary and ambiguous signal. The platform team responsible for the product should combine usage data with open questions about what worked, what failed, what should improve, and what upcoming work will require. Avoid yes-or-no questions that reveal no reason or future need. Körbächer strongly favors written feedback because it can be retained and examined rather than remembered as conversational noise.
Presentation Notes: Measure Before Building
If measurement starts only after launch, there is no baseline against which to assess improvement. Körbächer recommends deciding what success means and observing the current state before introducing the platform.
Candidate indicators mentioned in the talk include:
- Active users and use of specific capabilities, such as documentation or a service catalog.
- Time from an internal need to a production deployment, even when there is no external market release.
- Changes in shadow IT or spending on external services.
- Developer flow, cognitive load, satisfaction, and qualitative experience.
- Whether adoption and user feedback improve as capabilities are added.
He reports two examples from client work. At Toyota, he says centralized platform documentation was used by almost everyone in IT because it replaced information scattered across hundreds of repositories, websites, and an intranet. At an unnamed large telecommunications customer, he says spending on external IT services dropped drastically soon after the unfinished platform solved one or two identified problems, removing much of the shadow IT. These are speaker-reported observations without figures or a controlled comparison, but they demonstrate the type of outcome a platform team can watch.
Körbächer is cautious about DORA metrics when management turns team-level delivery signals into targets or performance rankings. Pressure to increase one number can distort behavior or sacrifice quality. He prefers the broader SPACE dimensions: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. He stresses that every metric needs context. For example, review time is not meaningful without considering the size and complexity of the change.
DevEx measures add a user-centered view through feedback loops, cognitive load, and flow state, but telemetry is not sufficient. Apparent correlations can be accidental, so the team must pair numbers with interviews and repeated feedback.
Presentation Notes: Treat Removal as Product Work
Platforms accumulate maintenance obligations as dependencies change, projects lose contributors, licenses shift, and user needs evolve. Sunk-cost thinking can keep an unused capability alive because the organization has already invested in it.
Körbächer recommends defining retirement criteria alongside purpose and success indicators. The transcript calls these "depreciation criteria," but the examples concern deprecating or removing a capability, not accounting depreciation. Persistent evidence that a workflow costs users more time, has become outdated, or causes more harm than value should trigger investigation and, when warranted, replacement or removal. A platform is not a concrete foundation that only grows upward; he compares it to a living, reshapeable thing.
This also makes the thinnest viable platform a risk-control mechanism. Every unvalidated component adds an adoption bet and a future maintenance burden.
Presentation Notes: Community and Organizational Change
Körbächer's closing compass is:
- Establish a clear purpose and principles.
- Conduct user research.
- Measure, learn, and adapt.
- Manage technical debt and accept continuous change.
- Build a community that can contribute to the platform.
- Challenge organizational processes when they prevent an effective workflow.
Inviting internal users to contribute creates ownership and can improve both adoption and satisfaction. This connects platform engineering with InnerSource: the platform team remains responsible for the product but does not monopolize every improvement.
The harder recommendation is what Körbächer labels challenging Conway's Law. He says a platform's form follows company processes and suggests designing an ideal platform workflow, then changing the organization to support it. He acknowledges that this is a multi-year change-management effort rather than a quick technical fix.
Synthesis: A Platform Is a Portfolio of Bets
The talk's ideas can be combined into a practical operating loop:
- Find repeated friction. Research current workflows and identify a problem shared by enough users to justify a platform capability.
- State the bet. Name the users, expected outcome, constraints, baseline, and evidence that would justify continuing or stopping.
- Ship the thinnest useful path. Minimize both migration effort and the maintenance surface introduced before adoption is known.
- Observe behavior and experience. Pair usage and flow indicators with repeated qualitative feedback.
- Adapt, expand, or retire. Promote demonstrated value, revise a mismatched workflow, and remove capabilities that cannot meet their purpose.
This framing is my synthesis, not Körbächer's explicit model. It makes three parts of his presentation reinforce one another: purpose defines the hypothesis, measurement tests it, and deprecation criteria prevent sunk cost from making the decision permanent. Community contribution then becomes evidence of engagement as well as a way to scale development.
The central lesson is not that technology is irrelevant. Feasibility and reliable implementation remain necessary. The lesson is that technical quality alone cannot establish desirability or viability. A platform team must do product discovery, organizational design, measurement, maintenance, and change management in addition to coding.
Canonical source: Max Körbächer, "Platform Engineering for Everyone - Success Can’t Be Coded", InfoQ Dev Summit Munich 2025 presentation and transcript, published July 20, 2026.