Internal developer platforms moved from buzzword to budget line quickly. Gartner has predicted that by 2026, 80% of software engineering organisations will have established platform teams, and the IDP category is now a multi-billion-dollar market with a clear set of credible options.
What has not changed is the failure rate. IDPs rarely fail because the technology does not work. They fail because developers quietly route around them. This guide covers the platforms and partners worth evaluating, the three-layer architecture that most buyers only discover halfway through, and the adoption test that predicts whether any of it will be used.
An IDP Is Three Layers, Not One Product
The most common early mistake is treating "internal developer platform" as a single product category. It is not. Most production stacks combine a portal, an orchestration layer and a standards layer — and no single tool covers all three well.
The layer teams most often skip is orchestration. It is entirely possible to deploy a beautiful service catalog that shows developers what exists while leaving them exactly as dependent on the platform team to provision anything new. That is a directory, not a platform.
Why IDPs Fail: The Adoption Test
Across the industry, IDP failures cluster around two causes: forcing adoption without discovering what developers actually needed, and deploying a framework like Backstage without the engineering headcount to sustain it.
Both produce the same outcome — a platform that exists and is not used.
The single most reliable signal is ticket volume to the platform team. If it has not fallen, the platform has not replaced the old workflow — it has decorated it. Self-service that generates support tickets is not self-service.
The second-best signal is whether new services start on the golden path by default, or get migrated onto it afterwards under management pressure. If adoption requires a mandate, the platform is not yet faster than the path around it.
The Platforms Worth Evaluating
Portal layer
Backstage — the open source framework Spotify created and donated to the CNCF. It holds roughly 89% share among organisations that have adopted an IDP, which makes it the category default. It is also a framework rather than a finished product: the plugin ecosystem requires ongoing maintenance and breaking changes are common. The widely repeated guidance is not to adopt Backstage without at least two full-time engineers committed to it, and that guidance is sound.
Port — a no-code commercial portal with customisable blueprints and production-grade self-service actions. Fastest time to value in this layer, with a free tier for evaluation. Frequently the right default for mid-market organisations that want a portal this month rather than next quarter.
Cortex — a commercial portal oriented toward service ownership and standards, aimed at engineering leadership needing visibility across hundreds of services.
Orchestration layer
Humanitec — a Platform Orchestrator that wraps your existing Terraform and CI/CD tooling. Its Score specification, now a CNCF sandbox project, lets developers describe workload requirements without writing Kubernetes manifests or Terraform, with the orchestrator translating that into cloud-specific resources. Requires a separate portal.
Kratix — an open source framework from Syntasso built around "Promises": composable platform capabilities exposed as Kubernetes APIs that developers consume like any other CRD. Highly flexible, and correspondingly demanding — it expects a platform team comfortable with controller-level work.
Crossplane — extends Kubernetes to orchestrate infrastructure of any kind through the Kubernetes API. Strong fit for teams already standardised on Kubernetes as the control plane.
Standards layer
Cortex and OpsLevel — scorecards and maturity rubrics that make ownership and engineering standards measurable. Genuinely valuable above roughly fifty services; usually premature below that.
Build, Buy or Partner
Three routes, with honest trade-offs.
| Route | What it looks like | The real cost |
|---|---|---|
| Build on open source | Backstage or Kratix, assembled and maintained in-house | Zero licence cost, but two or more dedicated engineers indefinitely. The maintenance does not end at launch. |
| Buy a product | Port, Humanitec or similar, adopted as SaaS | Licence fees and faster time to value, but you still need someone to define golden paths. The product does not know your architecture. |
| Partner | An external team designs, builds and operates the platform with you | A retainer, and a real risk of building something your developers did not ask for if discovery is skipped. |
The route that fails most quietly is building on Backstage without staffing it. The licence cost is zero, so it reads as the cheap option in a budget conversation — right up until the plugin maintenance becomes someone's full-time job.
Where SquareOps and Atmosly Fit
We build Atmosly, an internal developer platform for Kubernetes covering self-service provisioning, golden paths and CI/CD automation. Our platform engineering services cover the design and build phases, and we also run the infrastructure underneath through managed Kubernetes, 24×7 SRE and CI/CD consulting.
That combination is the unusual part. Platform vendors ship the product but do not operate your clusters. Consultancies operate clusters but do not ship a platform. Doing both means the golden paths we define are ones we are also on call for — which is a meaningful constraint on designing paths that look elegant and break in production.
We are a reasonable fit if you are Kubernetes-based, want the platform layer and the operations underneath it from one team, and would rather not staff a platform function from scratch.
We are the wrong choice if your requirement is an open source mandate — Backstage, Kratix or Crossplane are the honest answers there, and Atmosly is not. Equally, if you need a service catalog for a large non-Kubernetes estate, Port or Cortex will serve you better than we will.
How to Evaluate a Platform Engineering Partner
- Ask how they measure adoption. If the answer is a feature list rather than ticket volume, time-to-first-deploy or golden path usage, they build platforms nobody uses.
- Ask what discovery looks like before anything is built. The most common failure is a platform designed around what the platform team found interesting rather than what developers were actually blocked on.
- Ask which of the three layers they cover and what they expect you to bring. Portal-only engagements leave provisioning exactly where it was.
- Ask about the escape hatch. Real services eventually need something the golden path does not cover. A platform with no supported exception route teaches developers to bypass it entirely.
- Ask who operates it afterwards. A platform is a product with a lifecycle, not a project with an end date. Someone owns upgrades, plugin maintenance and new golden paths in perpetuity.
- Confirm the code lives in your repositories — templates, policies and platform definitions in your Git from day one.
What It Costs
- Open source — no licence fee, and a realistic floor of two engineers for Backstage. Budget the headcount, not the software.
- Commercial platforms — typically priced per developer or per service, with free tiers available for evaluation at the portal layer.
- Partner-led — a design and build phase followed by an operating retainer. Most economical when bundled with the Kubernetes operations underneath rather than contracted separately.
The comparison that matters is not platform cost against zero. It is platform cost against the engineering time currently lost to provisioning tickets, onboarding delays and inconsistent service setup.
Making the Decision
Start with the bottleneck, not the tooling. If developers cannot find what exists, you need a portal. If they can find it but still file tickets to get anything provisioned, you need orchestration. If services are inconsistent and ownership is unclear, you need standards. Most teams need two of the three, and buying the wrong one first is the usual reason platform projects stall.
Then run the adoption test on whatever you build. A platform that is technically excellent and unused is a more expensive failure than no platform at all.
If you are running Kubernetes and want a developer platform delivered by a team that also operates the infrastructure beneath it, explore our platform engineering services or talk to our team. We will assess where your developers are actually blocked and tell you honestly which of the three layers to build first — including when an open source route serves you better than we would.
For related reading, see our reviews of managed Kubernetes service providers and managed DevOps and SRE companies in India, or our case studies.
