Everybody Wants a K8s IDP Until They Realize They're Building a Product Company Inside Their Company

The fantasy version of an internal developer platform is hard to resist. Developers click a clean form, request a new service or cluster, and the platform quietly handles the ugly details in the background. Fewer support tickets. Better consistency. Less Kubernetes trivia leaking into every application team. Everybody wins. That is the sales pitch. The actual conversation around self-hosted IDPs is far less romantic. A recent Kubernetes thread captured the problem perfectly. The original goal sounded reasonable enough: a self-hosted internal platform that would make cluster creation and resource management easier through forms and workflows. But the moment the options came up, so did the warnings. Backstage looked powerful, but also heavy. Commercial tools looked polished, but sometimes less self-hostable than their marketing implied. Open alternatives existed, but each one came with different gaps, setup costs, and hidden product work. That is the real story of K8s IDPs right now. Most teams are not choosing a tool. They are choosing how much software company they are willing to become. ## The smartest advice in the thread was basically: stop trying to skip the middle The most useful comment in the discussion was also the least glamorous. Do it iteratively. That was the advice. Build the first cluster by hand so you actually understand what you are abstracting. Build the second one with plain GitOps ideas and very little cleverness. Copy the next few. Only after the patterns are obvious should you decide what deserves a real platform workflow. That sounds almost boring, which is exactly why it is good advice. Teams get into trouble with IDPs when they start by designing the polished interface instead of discovering the real operating model. If you do not yet know which variables are stable, which workflows are actually repeated, and which exceptions keep showing up, your "platform" will mostly be a beautiful machine for generating future disappointment. Another commenter described a far simpler setup that already solved a lot of the internal pain: developers authenticate, click a few predefined options, an Ansible-backed workflow writes the manifests, merges them, and Flux deploys the result. No giant platform rewrite. No massive React problem. Just enough workflow to remove repetitive human mediation. That answer mattered because it pointed to something platform teams often forget. The first useful IDP is usually much uglier than the first ambitious one. ## Backstage is attractive for a reason, but the warning labels are real Backstage keeps showing up because it offers what many teams actually want: a place for forms, workflows, service ownership, docs, and platform entry points to live under one roof. The issue is not whether it can do useful things. The issue is what it takes to make it feel native to your organization. One of the thread’s recurring themes was that Backstage is best documented and often the most capable place to build a custom internal experience, but it also demands serious commitment. If your team does not have the appetite for frontend work, plugin maintenance, integration glue, and ongoing product ownership, the dream can turn into a long, expensive detour. That is why several replies kept converging on the same compromise position. Use Backstage if you really need a custom UI and understand what you are signing up for. If not, start with lighter workflows, existing CI, or simpler orchestration layers that solve the operational bottleneck first. This is the part IDP conversations often skip. The internal platform is itself a product. It has users, support cost, roadmap debt, feature requests, and maintenance burden. You are not escaping product work. You are choosing to do product work for internal customers instead of external ones. That can still be the right move. It just should not be mistaken for a shortcut. ## A lot of teams do not need an IDP. They need fewer support interrupts. One of the most grounded replies in the thread came from someone who openly described their solution as "IDP-lite." They did not go full Backstage. They built reusable charts, simple form-triggered workflows, and enough structure to make common requests repeatable. That approach is not flashy, but it reveals the actual value proposition. For many organizations, the point of an IDP is not to create a magical platform brand. It is to stop bothering a small group of infrastructure people every time a developer needs the same predictable thing. If a lightweight form plus GitOps plus templates removes that repetitive support loop, then the platform is already doing its job. That is why the more mature comments in the thread sounded cautious rather than excited. They were not asking how to build the coolest portal. They were asking which abstraction would survive contact with reality. And reality in platform work usually looks like this: half the effort goes into integration, a quarter goes into permission and policy edges, and the rest goes into explaining why the "simple portal" does not magically remove the need to understand the systems underneath. ## The trap is trying to industrialize too early The danger with self-hosted IDPs is not just technical overreach. It is premature standardization. If your team starts building a universal interface before your underlying workflows are truly stable, you freeze a bunch of assumptions too early. Then every weird exception becomes a plugin, every special case becomes another branch in the workflow, and every request for flexibility becomes a product debate. That is how internal platforms get bloated. The iterative advice in the thread was a quiet rejection of that trap. Learn by doing the work manually first. Then automate the repeated parts. Then add a cleaner entry point. Then decide whether you actually need a broader platform layer. It is less elegant than the platform-engineering fantasy, but it is far more likely to produce something people trust. ## The best IDP decision might be a smaller one than you expected The strongest takeaway from the discussion was not "choose this tool." It was "choose the smallest useful commitment." Maybe that is Backstage with a narrow scope. Maybe it is a lightweight orchestration layer with forms and GitOps behind it. Maybe it is a self-hosted alternative that gets you eighty percent of the way there without turning your platform team into a frontend team. Maybe it is not really an IDP yet at all, just a better way to turn repeatable cluster tasks into safe workflows. That answer is less satisfying to people who want a clean category. But it is much more honest. Because everybody says they want a Kubernetes IDP. What they usually mean is that they want fewer tickets, fewer bespoke requests, fewer support escalations, and fewer developers tripping over the same platform edges. That is a worthwhile goal. It just does not always require building a mini software company inside your own.