Platform Engineering Is Mandatory Now. Here's the Minimum Viable IDP.

Platform engineering stopped being a competitive edge and quietly became a baseline. The 2025 DORA Report, built on survey responses from nearly 5,000 technology professionals, found that 90% of organizations now run an internal developer platform and 76% have a dedicated platform team. Gartner has been projecting for a while that 80% of large software organizations will have platform teams by 2026, up from 45% in 2022. When something crosses 90% adoption, the interesting question is no longer whether to do it. It's how to do it without lighting a pile of money on fire.

And that's where most teams go wrong. They hear “internal developer platform,” they picture Spotify, and they go stand up Backstage with a dozen plugins and a squad of operators to babysit it. Six months later they have a portal nobody logs into, a platform team drowning in support tickets, and developers who still deploy the way they always did. The platform became the project instead of the thing that makes projects faster.

I want to argue for the opposite. A minimum viable IDP is three things, and only three: a portal, one paved path, and FinOps guardrails. Ship those, prove they get used, then earn the right to add more. Everything else is premature.

Why this is suddenly non-negotiable

The adoption numbers alone would make platform engineering a safe bet. But the reason it turned into a must-have is buried in DORA's central 2025 finding, and it's about AI. Nearly everyone is using AI now. DORA found 90% of respondents use AI at work and over 80% believe it made them more productive, though 30% still report little or no trust in AI-generated code. That last number is a healthy instinct, by the way.

Here's the part that should reorganize your roadmap. DORA found that AI is an amplifier, not a lever. When internal platform quality is high, AI adoption has a strong positive effect on organizational performance. When platform quality is low, that effect is negligible or even negative. Read that again. Rolling out AI tooling on top of a weak platform can make your organization perform worse, not better.

This makes intuitive sense once you sit with it. AI lets people generate and ship more code, faster. If your paths to production are solid, tested, and observable, more throughput compounds into more value. If your paths are brittle and manual, more throughput just means more broken things arriving faster, and now a chunk of it is code the author doesn't fully trust or understand. The platform is the thing that turns velocity into progress instead of chaos.

So the case for a minimum viable IDP in 2026 isn't “everyone else has one.” It's that you're already pouring AI into your engineering org, and without a decent platform underneath it, you're amplifying whatever's already there, including the mess.

Piece one: a portal that answers “where is everything”

The first thing a developer loses in a growing org is the map. Which services exist. Who owns them. Where the runbook is. What depends on what. What's the on-call rotation for the thing that just paged you. In a ten-person startup this lives in people's heads. At a hundred engineers it's gone, and the cost shows up as Slack archaeology and “who owns billing-service” threads.

A portal fixes exactly that, and it's the least glamorous, most valuable piece. A service catalog with ownership, docs, dependencies, and links to the dashboards. That's the whole job at the start. Notice what it is not: it is not a dashboard for everything, not a plugin marketplace, not a single pane of glass for your entire cloud. It's an answer to “where is this and who owns it.”

This is where Backstage enters, and where I'd slow you down. Backstage is genuinely impressive. Spotify open-sourced it in March 2020, it joined the CNCF that September, and it moved to CNCF Incubating status in March 2022, where it still sits in 2026. It now has more than 3,400 adopters, including Airbnb, Booking.com, LEGO, Toyota North America, and Philips, around 1,600 contributors, over 230 plugins, and by 2025 it ranked sixth in velocity among more than 230 CNCF projects. That is a serious, living project.

But Backstage is a framework for building your own portal, not a portal you install. Those 230-plus plugins are components you assemble and maintain. Teams routinely underestimate how much platform work it takes just to keep Backstage itself healthy. For a first IDP, that's exactly the trap: you set out to reduce toil and end up operating a portal platform that generates its own toil.

The point of the portal isn't the tool. It's that DORA identified the platform capability most correlated with positive developer experience as giving “clear feedback on the outcome of my tasks.” A portal that tells a developer where things are and what state they're in is the front door to that feedback. Feature breadth loses to knowing what's going on.

Piece two: one paved path from commit to running service

The paved path is the heart of the whole thing. It's the golden, supported, boring route that takes a developer from “I pushed code” to “it's running in production” without a single ticket, a single manual step, or a single Slack message to the platform team. Commit, and the pipeline handles build, test, security scan, deploy, and observability wiring on its own.

The word that matters is one. Not a path per team. Not a configurable framework with forty knobs. One opinionated, blessed way to ship the most common kind of service you build, whether that's a containerized web API or a background worker. Pick your single most common workload and make that path excellent. Everything else can keep using the old way for now.

This is also the piece that decides whether AI helps or hurts you. Remember DORA's amplifier finding. The paved path is where velocity turns into either value or wreckage. If every AI-assisted commit flows through a path that runs tests, scans for vulnerabilities, and wires up logging and metrics automatically, then more code means more well-instrumented, tested code. If it doesn't, more code just means more unreviewed surface area, and now some of it was written by a model the author admits they don't fully trust.

There's a design warning baked into the DORA data too. Teams without a user-centric focus actually experience negative impacts from AI adoption, while teams with strong user focus see amplified benefits. In platform terms: do not build the paved path from a wishlist. Build it from watching what developers actually do all day. The best platform teams treat the path as a product, measure how many teams adopt it, and rip out steps nobody walks. A paved path with no traffic is just a maintenance burden with good intentions.

Piece three: FinOps guardrails, before the bill lands

Here's the piece most “minimum viable IDP” takes leave out, and it's the one with the clearest dollar figure attached. Harness's FinOps in Focus 2025 report projects $44.5 billion in cloud infrastructure waste for 2025, roughly 21% of enterprise cloud infrastructure spend lost to underutilized resources. One out of every five dollars, gone to things nobody's using.

The report is blunt about the cause, and it's an org-design problem, not a technology one. 52% of engineering leaders said the disconnect between FinOps and development teams causes wasted cloud spend, and 62% of developers said they actually want more control over managing cloud costs. The developers aren't indifferent. They're flying blind. Fewer than half of respondents have real-time visibility into idle resources (43%), orphaned resources (39%), or over- and under-provisioned workloads (33%), and a striking 55% of developers said purchasing commitments are based on guesswork.

And the clock is brutal. Harness found organizations take an average of 31 days to identify and eliminate cloud waste, and about 25 days to detect and rightsize overprovisioned resources. A month of leakage before anyone even notices the leak. That's not a spending problem, it's a feedback-loop problem, which is precisely what a platform is supposed to fix.

So the guardrails belong in the paved path, not in a quarterly finance review. Concretely, the minimum is small: every resource the path creates gets tagged with its owning service automatically, so cost is attributable from day one. Developers see spend per service in the same portal where they see ownership. Idle and orphaned resources get flagged automatically instead of discovered 31 days later. And the path sets sane defaults so that spinning up something oversized takes a deliberate choice, not an accident.

This is only getting more urgent because the shape of the spend is changing. The FinOps Foundation's State of FinOps 2026 report, its sixth annual edition, surveyed 1,192 practitioners representing over $83 billion in annual cloud spend. It ranked workload optimization and waste reduction as the top current priority, with “FinOps for AI” the leading forward-looking focus. AI spend management adoption jumped to 98% of FinOps practitioners in 2026, up from 63% in 2025. Cost governance is racing toward AI workloads, and those workloads are expensive and easy to leave running. If your platform doesn't make that spend visible at the point of creation, you're volunteering to be part of the $44.5 billion.

What a minimum viable IDP is not

Half of building the right platform is refusing to build the wrong one. The failure mode isn't doing too little, it's doing too much too early. A few things I'd explicitly leave out of version one:

• A plugin for everything. Every integration you add is something you now operate and keep secure. Add the two or three that real users ask for twice. Ignore the rest.
• A path per team.The value of a paved path is that it's the same road for everyone. The moment you have five paths you have five things to maintain and no standardization, which is the problem you were trying to solve.
• A twelve-person platform empire.A big platform org becomes its own bureaucracy, and bureaucracy is friction, and friction is the exact thing you're fighting. A small team that treats the platform as a product beats a large team that treats it as a fiefdom.
• Governance dressed up as a platform. If your IDP is mostly gates, approvals, and policy enforcement, developers will route around it. Guardrails should make the safe path the easy path, not turn the platform into a checkpoint.

How I'd sequence it

If I were starting from zero, I'd go in this order, and I'd resist the urge to parallelize it into a big-bang launch.

1. Catalog first.Stand up the lightest possible portal that answers ownership and “where is it.” You'll use it immediately and it's the cheapest to ship. Skip Backstage unless and until a simpler catalog genuinely runs out of room.
2. One paved path next. Pick your single most common service type. Make commit-to-production for that type automatic, tested, scanned, and observable. Get one team using it happily before you offer it to a second.
3. Guardrails woven into the path. Auto-tag every resource by owning service, surface per-service spend in the portal, and flag idle resources automatically. Close the 31-day feedback gap down to something a developer sees the same week.
4. Then, and only then, expand. Add a second path, more catalog automation, or Backstage, driven by measured demand and adoption numbers, not by a roadmap you wrote before anyone used the thing.

The through-line is feedback. DORA's strongest developer-experience signal was clear feedback on task outcomes, and every one of these pieces is a feedback loop. The portal tells you where things are. The paved path tells you fast whether your change is good. The guardrails tell you what it costs before the invoice does. Breadth of features is not what makes a platform good. Tight, honest feedback is.

Platform engineering being mandatory doesn't mean the maximal version is mandatory. It means the outcome is: developers who can find things, ship safely without tickets, and see what they spend. You can deliver all three with a portal, a paved path, and FinOps guardrails. Everything past that is a choice you should earn, not a starting cost you should pay. Given that platform quality now decides whether the AI you already bought helps or hurts, getting these three right isn't a nice project for next quarter. It's the thing holding up everything else.