Skip to main content

Adoption roadmap

Adopting an internal developer platform is an organizational change, not just a deployment. This roadmap phases it so you prove value early, expand on evidence, and only take on multi-cluster complexity once it's earned. Each phase lists its goal, what to deliver, success criteria, and what leadership must sponsor.

The Fedshi reference instance — all planes in one GKE cluster at https://console.idp.fedshi.com — is exactly the Phase 0/1 topology, so the early phases are a well-trodden path.

tip

Don't skip Phase 0. The single most common way platform programs fail is going broad before proving value with one team. Phase 0 produces the evidence that funds everything after it. Tie each phase to the metrics baseline so "are we ready to expand?" is a data question, not a debate.

Phase 0 — Pilot (one team, single cluster)​

Goal: prove that DevsPortal delivers real developer velocity and standardization for one team, on the simplest production-capable footprint, fast.

What to deliver:

  • A single-cluster DevsPortal instance — control, data, workflow, and observability planes co-located (the Fedshi topology), with registry, identity, secrets, and observability wired up.
  • One or two golden-path templates that cover the pilot team's most common service shape (e.g. a web service and a worker).
  • The pilot team onboarded: deploying through the portal, promoting across at least dev → staging, and viewing logs/metrics/traces.
  • A baseline captured for the chosen KPIs before the team moves over.

Success criteria:

  • The pilot team's first production deploy goes out through the platform.
  • Measurable movement on 2-3 KPIs vs. baseline — typically onboarding time and lead time — even on a small sample.
  • The pilot team would choose to keep using it (qualitative but decisive).

What leadership must sponsor:

  • A small dedicated platform owner (even one engineer) for the pilot's duration — not a side-of-desk effort.
  • A willing pilot team with real workloads and air cover to try a new way of shipping.
  • Budget for one cluster and the engineer's time. This is the cheapest phase by design.

Phase 1 — A few teams (shared platform, one cluster)​

Goal: show the platform holds up as a shared, multi-tenant service and that golden paths generalize beyond the first team.

What to deliver:

  • 3-5 teams onboarded onto the shared instance, each in its own isolated Project (cell) with RBAC and network policy.
  • An expanded golden-path catalog covering the additional service shapes the new teams need, plus shared ResourceTypes (databases, queues) where common.
  • A repeatable team-onboarding runbook so adding a team is a documented, self-service action, not a bespoke project.
  • KPI tracking rolled up across teams, with the % on golden paths watched as the leading indicator.

Success criteria:

  • New teams onboard via the runbook without bespoke platform work each time.
  • A meaningful share of the participating teams' services run on golden paths.
  • KPI trends from Phase 0 hold or improve at larger scale; no tenancy or isolation surprises.
  • A small platform team (not one person) is now operating it sustainably.

What leadership must sponsor:

  • Formation of a standing platform team with a product mindset (treat the IDP as an internal product with users).
  • A mandate that participating teams adopt golden paths rather than route around them — governance only works if it's backed.
  • Budget for the platform team and any capacity headroom on the shared cluster.

Phase 2 — Org-wide / multi-cluster​

Goal: make DevsPortal the default way software ships across the organization, and scale topology to meet real-world demands (capacity, regions, data residency, environment separation).

What to deliver:

  • Broad onboarding toward org-wide coverage, with golden paths and ResourceTypes that reflect organization-wide standards and compliance requirements.
  • Multi-cluster topology where warranted — additional data planes (for scale, regions, or data-residency) and/or separated planes, added additively via the outbound-mTLS connectivity model without changing the security posture.
  • Production-grade operations: SLOs for the platform itself, upgrade and rollback runbooks, on-call, and integration with org identity and policy.
  • A governance model for evolving golden paths as a shared asset across teams.

Success criteria:

  • The large majority of new services launch on golden paths by default.
  • Org-wide KPI improvements are visible and reported (DORA + onboarding + cost).
  • The platform meets its own reliability SLOs, including across clusters/regions.
  • Standing up a new team or a new environment is routine and self-service.

What leadership must sponsor:

  • A funded, ongoing platform organization with clear ownership and roadmap.
  • An executive mandate that golden paths are the default path to production.
  • Budget for multi-cluster infrastructure and the operational maturity (SLOs, on-call) that org-wide dependence requires.

How to know you're ready to advance​

Move to the next phase when the current one has met its success criteria with evidence, not on a calendar. Concretely:

  • 0 → 1 when the pilot team's KPIs moved and they'd keep using it.
  • 1 → 2 when team onboarding is repeatable, golden-path coverage is climbing, and a standing platform team is operating it sustainably.

Each phase de-risks the next: Phase 0 proves value cheaply, Phase 1 proves it scales as a shared service, Phase 2 makes it the organizational default. Track the whole journey against the outcomes & metrics baseline, and revisit the business value framing as the evidence accumulates.