Internal developer platform build service: Backstage, ArgoCD and Crossplane golden paths for Indian teams in 2026

Summary. CNCF and SlashData surveyed more than 400 professional developers for the Q1 2026 Technology Radar, published on 24 March 2026, and the numbers say most internal developer platforms are not owned by anyone in particular. Only 28% of organisations report a dedicated platform engineering team. The most common model, at 41%, is multi-team collaboration on platform capabilities, and 35% report using a hybrid platform that bolts specialised AI tooling onto an existing developer platform. On the tooling side the picture is much clearer: Backstage, Helm and kro sit in the Adopt position for application delivery, ArgoCD, Armada, Buildpacks, GitHub Actions and Jenkins are in Adopt for workflow automation, and cert-manager, Keycloak and Open Policy Agent are in Adopt for security and compliance. Helm scored highest for maturity, with 94% of developers giving it four or five stars for reliability and stability. GitHub Actions hit 91% peer recommendation, and cert-manager 87% for stability. The commercial alternatives are not cheap: Spacelift's Starter+ tier is an annual subscription starting at $20,000/year, and Terraform Enterprise, judging from the AWS and Azure Marketplace listings, starts from $15,000/year with five workspaces included.

The tooling debate is settled. The ownership problem is not. That gap is where most IDP projects fail.

What the CNCF Q1 2026 data actually shows

The survey ran in Q4 2025 across more than 400 professional developers using cloud native technologies, who rated tools they were familiar with on maturity, usefulness and likelihood to recommend. Three findings matter for anyone planning a platform.

First, dedicated platform teams are the minority. At 28%, they are outnumbered by the 41% running multi-team collaboration. That second model sounds collegial and usually is not — it means the platform is a shared side project, maintained by whoever last needed it to work.

Second, AI workloads are being folded into existing platforms rather than given their own stack. 35% report a hybrid platform combining existing developer platforms with specialised AI tooling. Chris Aniszczyk, CTO of CNCF, put the trend this way: "Cloud native platforms have reached a point where developers are not just experimenting but standardizing on CNCF projects that make software delivery reliable at scale."

Third, developer selection criteria have shifted from capability to fit. Liam Bollmann-Dodd, principal market research consultant at SlashData, described what the data shows: "Developers are increasingly evaluating tools based on how well they fit into their internal platform architectures."

The report also notes that Backstage and kro performed strongly on usefulness. Read that alongside Helm's maturity lead and the shape of a sensible 2026 stack falls out: Helm for packaging because it is boring and proven, Backstage for the developer-facing surface, ArgoCD for delivery, cert-manager and OPA for the guardrails, and a careful eye on supply-chain tooling that is still maturing.

The three components, and what each is actually for

Teams routinely buy all three and use none of them properly, because the boundaries are not obvious from the marketing.

Backstage is a catalogue and a front door, not a platform. It answers "what services exist, who owns them, where are the docs, and how do I create a new one that follows our rules". Its value is the software catalogue and the scaffolder templates. Its failure mode is being deployed as an empty portal with a stale catalogue that nobody opens twice. Backstage sits in CNCF's Adopt position for application delivery on usefulness, which is the right read: it is useful when populated, and inert when not.

ArgoCD is the delivery mechanism. It reconciles what is running in the cluster against what is declared in Git. That reconciliation loop is the part that makes a platform trustworthy, because it means "what is deployed" has a single answer that a human can read. ArgoCD sits in Adopt for workflow automation.

Crossplane is the infrastructure control plane. It lets you expose an opinionated API — "give me a Postgres" — that provisions the underlying cloud resource with your organisation's defaults baked in. It is the piece that stops golden paths from being documentation and makes them executable. Crossplane was not in the Adopt list from this particular survey, and that is worth stating plainly rather than glossing over: it is the least settled of the three, and teams should pilot it before committing.

The mistake that kills most IDP projects

The failure is almost never technical. It is that the platform is built as a portal instead of a path.

A portal is a place engineers are told to go. A golden path is the fastest route to production, which engineers take because it is fastest. If your Backstage scaffolder produces a service that still needs three manual tickets to reach production, engineers will keep raising the three tickets and skip the scaffolder. The platform then shows low adoption, leadership concludes the tooling was wrong, and the next attempt buys a different tool.

The test is uncomfortable but simple. Time a new engineer creating a service from scratch to a running staging deployment. If the golden path is not the fastest route, it is not a path.

The second failure is the 41% problem from the CNCF data. A platform maintained by multi-team collaboration has no roadmap, no on-call, and no one who says no. It accretes special cases until it is harder to use than the thing it replaced. A platform needs a named owner even when it does not need a full team.

A sequencing plan that does not stall in month three

This is the order we build in, and the reasoning behind it.

1. Catalogue before portal. Populate the service catalogue with real ownership data before anyone sees a UI. An empty Backstage instance burns credibility you only get once.

1. One golden path, end to end. Pick the most common service shape in your estate. Take it from scaffold to production with zero manual tickets. One complete path beats five partial ones.

1. GitOps one environment. Put staging fully under ArgoCD before touching production. The reconciliation loop teaches you where your drift lives.

1. Policy as enforcement, not advice. Move three standards from a wiki into Open Policy Agent checks that fail CI. Three enforced rules change behaviour more than thirty documented ones.

1. Self-service one resource type. Use Crossplane to expose a single infrastructure API — usually a database — with your encryption, backup and tagging defaults built in.

1. Certificates and identity. cert-manager and Keycloak are in CNCF's Adopt list for good reason, and both remove a recurring class of ticket.

1. Measure, then widen. Track time from repository creation to first production deploy. If that number is not falling, stop adding features and find out why the path is being avoided.

Each step ships something usable. That matters because platform work has no external deadline, so it loses every prioritisation argument unless it produces visible wins early.

Build, buy, or a managed platform

There are three honest options and the right answer depends on your team size more than your technology.

Buying a commercial platform is the fastest route for a small team and the most expensive at scale, because the pricing meters do not care whether the platform is well used. As covered in our analysis of Terraform 1.16 lifecycle changes, HCP Terraform bills per managed resource, and Spacelift's own tier structure starts its Starter+ annual subscription at $20,000/year with Terraform Enterprise listed from $15,000/year for five workspaces. Those are real numbers to weigh against engineering time.

Building on open source is cheaper in licence terms and more expensive in attention. The CNCF-adopted stack is genuinely production-grade, and Helm's 94% reliability rating reflects a decade of hardening. What you take on is integration, upgrades and the ownership problem the survey data exposes.

The third option is building on open source with an external team doing the integration and the first year of hardening, then handing over. That is the engagement most Indian mid-size organisations get the best result from, because it converts an indefinite internal project with no owner into a scoped piece of work with a delivery date.

India-specific considerations

Three things differ here and all three are underweighted in imported platform advice.

The economics invert. Engineering time is cheaper relative to a dollar-denominated licence, so the buy case that carries US organisations is weaker. A $20,000/year platform subscription converts to roughly ₹17,60,000 a year at about ₹88 to the dollar in August 2026, recurring, before any usage-based component. That funds a meaningful amount of senior engineering time in Gurugram or Pune. The catch is that it only helps if someone is actually assigned to the work.

GCC scale changes the shape. Indian global capability centres often run more teams and more services per platform engineer than the organisations these tools were designed around. That pushes the catalogue and ownership problem to the front. If 200 services have no recorded owner, no amount of scaffolder tooling fixes the operational reality. Organisations weighing this structurally should look at the GCC versus product partner build decision.

DPDP makes policy enforcement a compliance artefact, not a nicety. Under the Digital Personal Data Protection Act 2023, an auditor asking how you ensure customer data is encrypted at rest across 200 services wants evidence, not intent. An Open Policy Agent rule that fails CI is evidence. A wiki page is not. This is the strongest argument for making the platform's policy layer real early, and it connects directly to how teams design data residency and DPDP cloud architecture.

What eCorpIT builds, and how the engagement runs

We build internal developer platforms on the CNCF stack rather than on a proprietary layer, because the tools in CNCF's Adopt list have the maturity evidence behind them and because our clients should be able to run the result without us.

A typical engagement runs in four phases. Discovery maps the existing estate, service ownership and the real deployment path, including the undocumented one people actually use. Foundation stands up the catalogue, GitOps delivery for one environment, and the first golden path end to end. Hardening adds policy enforcement, certificate automation, identity and self-service infrastructure APIs. Handover trains the internal owner, documents the runbooks and hands over the repositories, with a support window while the team takes it on.

We are deliberate about scope. We do not attempt every golden path in phase one, because a platform that covers one service shape completely earns more adoption than one that covers five shapes partially. We insist on a named internal owner before the foundation phase starts, because the CNCF data on the 41% collaboration model matches what we see: platforms without owners do not survive their first quarter.

eCorpIT was founded in 2021 and works from Gurugram. We are CMMI Level 5 assessed, MSME certified and ISO 27001:2022 certified, and we hold partnerships with AWS, Microsoft and Google. We design platforms aligned with DPDP requirements and with the control expectations of ISO 27001 and SOC 2 audits, rather than claiming an audit outcome on your behalf. Related work includes release engineering and CI/CD platform builds and managed Kubernetes AI platform services.

Who this is not for

Worth saying plainly. If you run fewer than about 15 engineers on a handful of services, a platform is overhead — use a managed PaaS and revisit in two years. If you have no one who can own the platform after handover, buy a commercial product instead, because an unowned open-source platform decays faster than a licensed one. And if your main problem is cloud spend rather than delivery speed, start with cutting cloud costs for Indian teams and come back to platform work afterwards.

FAQ

How eCorpIT can help

eCorpIT builds internal developer platforms on Backstage, ArgoCD, Helm and Crossplane, sequenced so each phase ships something engineers use rather than a portal they ignore. Our senior-led teams run discovery, stand up the catalogue and the first golden path, harden policy and identity, then hand the platform to a named internal owner with runbooks and training. We are CMMI Level 5, MSME and ISO 27001:2022 certified, and we design platforms aligned with DPDP requirements. If your deployment path has become the bottleneck, talk to our engineering team.

References

1. CNCF and SlashData Report Finds Platform Engineering Tools Maturing as Organizations Prepare for AI-Driven Infrastructure - CNCF, 24 March 2026.

1. Q1 2026 CNCF Technology Radar report - CNCF and SlashData.

1. CNCF Backstage Documentary Highlights Project Evolution to Global Open Source Standard for Platform Engineering - CNCF, 25 March 2026.

1. CNCF Backstage Documentary Highlights Project Evolution to Global Open Source Standard for Platform Engineering - PR Newswire, March 2026.

1. CNCF Projects - Cloud Native Computing Foundation.

1. Terraform Cloud/Enterprise Pricing - Tiers Overview 2026 - Flavius Dinu, Spacelift, updated 6 August 2026.

1. SlashData - analyst firm that ran the CNCF Technology Radar survey.

1. CNCF Annual Report 2025 - CNCF, 24 February 2026.

1. How to Build an Internal Developer Platform: Backstage, ArgoCD, and Crossplane - freeCodeCamp.

1. CNCF Backs Backstage As Open Source Industry Standard - Open Source For You, March 2026.

1. Internal Developer Platforms 2026: How Backstage and Platform Engineering Are Transforming Developer Experience - Programming Helper Tech.

1. HashiCorp Product Pricing - HashiCorp, accessed 9 August 2026.

Last updated: 9 August 2026.