How long did it take to roll out the internal developer platform across all 40+ squads?

The core platform build took 5 months, followed by a phased rollout starting with two pilot squads to validate the golden paths under real workloads. Platform-wide adoption across all squads was completed within a 10-week rollout window, supported by a dedicated migration buddy assigned to each team.

Do we need to already use Backstage or Argo CD for this approach to work?

No. This organization standardized on Backstage, Argo CD, and Crossplane as part of the engagement, but the underlying pattern — a self-service catalog, GitOps-based deployment, and policy-guarded provisioning — can be built on whatever tooling a team already has. The key requirement is a willingness to consolidate on one paved road rather than supporting every team's bespoke deployment scripts indefinitely.

What was the biggest risk in a migration touching every product squad?

The biggest risk was disrupting in-flight delivery for 40+ squads simultaneously. That risk was managed by validating the golden paths with two pilot squads first, then rolling out over ten weeks with a dedicated migration buddy per team rather than a single big-bang cutover.

Would this approach work for a smaller engineering organization, not just 40+ squads?

Yes — the same self-service templates, ephemeral preview environments, and embedded security scanning reduce toil even for a handful of teams, since the ticket-driven bottleneck this solves appears well before an org reaches 40 squads. Smaller organizations typically need a shorter pilot phase and can skip the multi-migration-buddy model in favor of one platform engineer coordinating the rollout.

Back to case studies

TechnologyDevOps ConsultingKubernetes Platform

Internal Developer Platform

Golden paths, self-service environments, and paved roads to production for a high-growth engineering organization scaling past 40 product squads without scaling its platform headcount.

Less toil for platform teams, faster onboarding for product engineers

Client

Confidential — high-growth technology

Industry

Technology

Timeline

5 months

Technologies

7+ tools

The Challenge

!Every new environment, certificate, or namespace required a ticket to the platform team, and typical turnaround stretched three to five business days. Product squads routinely blocked entire sprints waiting on infrastructure that should have taken minutes to provision.

!Each squad had evolved its own bespoke way of deploying microservices, some using hand-rolled shell scripts, others wiring Jenkins jobs directly to kubectl. This meant every incident, migration, or platform upgrade required relearning a different deployment model team by team.

!New hires spent their first two to three weeks piecing together tribal knowledge from Slack threads and departed engineers' half-finished wiki pages. There was no single source of truth for how a service was supposed to be built, tested, and shipped.

!Security scanning was bolted on at the very end of the release cycle, often as a manual gate right before a production deploy. Vulnerabilities were routinely discovered days or weeks after code was written, forcing costly context-switching to remediate.

!Observability was inconsistent across services: some emitted rich traces and metrics, others shipped nothing beyond stdout logs. When incidents crossed service boundaries, on-call engineers lost critical time just figuring out which dashboards, if any, existed.

!Access provisioning to cloud resources was handled through a mix of manual IAM edits and ad hoc Terraform changes reviewed by a single overloaded platform engineer. This created both a single point of failure and an audit trail that was nearly impossible to reconstruct.

!Preview and staging environments were shared and frequently contended, so testing a change often meant waiting for another team to finish, or worse, silently overwriting someone else's in-flight test data.

!Platform engineers spent the overwhelming majority of their week on repetitive, low-value requests rather than on architecture or tooling investment, leaving no capacity to address the root causes driving the ticket queue in the first place.

!Incident response suffered from the same fragmentation as deployment: when a production issue spanned two services owned by different squads, responders often discovered mid-incident that the two teams used different logging formats and different alerting tools, adding precious minutes to diagnosis exactly when speed mattered most.

!Leadership had also lost the ability to answer a simple question — how many services exist, who owns each one, and what is its current health — because the service catalog, where one existed at all, was a wiki page that individual teams updated inconsistently or not at all.

Our Solution

We stood up a service catalog in Backstage with vetted templates for REST APIs, background workers, and batch jobs, so any engineer could scaffold a production-ready service in minutes with sane defaults for logging, health checks, and CI already wired in.

We standardized GitOps repository structure across every squad using Argo CD, giving each team an identical mental model for how manifests, overlays, and promotions worked regardless of what the service actually did.

Every pull request automatically received its own ephemeral preview environment, provisioned via Crossplane and torn down on merge, eliminating the shared-environment contention that had been silently corrupting test results.

We embedded SAST, dependency vulnerability scanning, and container image signing directly into the default GitHub Actions pipeline templates, so every commit was checked automatically rather than relying on a late manual gate.

Cloud resource provisioning moved to Crossplane-managed compositions with policy guardrails, replacing manual IAM edits with declarative, reviewable, auditable claims that any engineer could self-serve within pre-approved boundaries.

We published golden-path documentation directly inside the Backstage catalog alongside each template, plus a weekly office-hours session, so adoption didn't depend on tribal knowledge or waiting for a platform engineer's availability.

OpenTelemetry instrumentation was baked into every service template by default, automatically wiring new services into existing dashboards and trace views so they were observable from their very first deploy rather than after an incident forced the issue.

We ran a phased migration, starting with two pilot squads to validate the golden paths under real workloads, then rolling out platform-wide over ten weeks with a dedicated migration buddy assigned to each team.

Standardized incident tooling and alert routing across every squad on top of the same observability layer used for day-to-day monitoring, so a cross-service incident now surfaces a single, correlated timeline regardless of which teams own the affected services.

Made the Backstage service catalog the authoritative, auto-populated source of service ownership and health status, pulling directly from deployment and observability data rather than depending on teams to manually keep a wiki page current.

Measurable Impact

Lead time

40-50% reduction

Typical services reached staging with fewer handoffs and far less rework, cutting lead time roughly in half compared to before the paved roads existed.

Onboarding

First week to production

New engineers shipped a real change to production in their first week using the self-service templates and docs, down from two to three weeks of tribal-knowledge gathering.

Platform load

60-70% fewer tickets

Self-service provisioning eliminated the bulk of repetitive tickets for certificates, namespaces, and IAM access, freeing platform engineers for architecture work.

Quality

100% of commits scanned pre-merge

Security and dependency checks ran automatically on every change instead of at a late manual gate, replacing a single pre-deploy checkpoint that caught issues days or weeks late.

Environment contention

Zero shared-environment conflicts

Per-PR ephemeral environments removed the shared-staging conflicts that had been corrupting test runs.

Observability coverage

100% of new services instrumented by default

Every new service shipped with traces, metrics, and dashboards wired in from day one, up from a patchwork where many services emitted only stdout logs.

Adoption

40+ squads in 10 weeks

All squads migrated onto the golden paths within the ten-week rollout window, supported by dedicated migration buddies.

Cross-service incident diagnosis

Minutes instead of tens of minutes

Responders now work from a single correlated timeline instead of losing the first ten-plus minutes reconciling logging formats across teams mid-incident.

“Our platform engineers stopped being a bottleneck. Teams still move fast, but now with rails that make the right thing the easy thing. We finally have time to invest in the platform itself instead of just keeping the ticket queue from drowning us. Even our incident calls changed — nobody spends the first ten minutes anymore just figuring out which dashboard to look at.”
E
Engineering director
Director of Platform, technology company (NDA)

Technology stack

BackstageArgo CDCrossplaneGitHub ActionsKubernetesHelmOpenTelemetry