Internal Developer Platform Rollout: 30/60/90 Blueprint

01The Plan at a Glance

02TL;DR for Engineering Leaders

An internal developer platform is a product, not a tool project. The first 90 days should produce a written charter, one paved path in production, and adoption reporting the platform team can defend to leadership. Skip any of those three and the rollout tends to stall by the second quarter.

Rollouts that succeed follow a narrow pattern: name a platform product manager on day one, ship one paved path end to end before adding a second, and measure weekly active platform users rather than catalog counts. Rollouts that fail typically defer product ownership, ship a broad catalog before proving any single paved path works, and report activity metrics that do not track adoption.

03Problem Definition

Roughly 70 percent of internal platform initiatives struggle with adoption or expected value, most often because they are run as tool projects rather than as products with named owners, defined users, and measurable adoption goals. The Puppet 2024 State of DevOps report found that 52 percent of respondents named a platform product manager as central to platform team success.

Rollouts consistently fail in one of five ways:

• launched without a platform product manager
• launched without a target developer segment
• launched with a broad catalog rather than one paved path proven end to end
• launched without an exception process
• launched without an adoption metric leadership agreed on in advance

This blueprint prescribes a 30/60/90 sequence that closes each of those gaps before broad rollout begins. It is written to be executed by a platform team of 2 to 5 engineers, a platform product manager, and an executive sponsor.

04Methodology Snapshot

This blueprint is built from StackAuthority's implementation-first framework. The framework prioritizes product ownership and paved path proof before broad catalog growth.

1. prioritize charter, target segment, and paved path scope before tool work
2. ship one paved path end to end before adding a second
3. instrument adoption before instrumenting features
4. build the exception path before the paved path reaches broad rollout
5. gate expansion on documented weekly active use, not on catalog size

For full methodology details, see Methodology. Use it to keep review criteria and evidence expectations consistent across phases.

05Target Operating Principles

1. Platform is a product: a charter, a named product manager, a target developer segment, and a roadmap exist before any code is written.
2. One paved path first: the first paved path is shipped end to end and used by at least two product teams before a second is started.
3. Adoption over activity: weekly active platform users as a percentage of eligible engineers is the primary metric; page views and catalog counts are secondary.
4. Exceptions are first class: the escape hatch process is documented, staffed, and used at least once before broad rollout.
5. Continuous review: platform product review runs on a weekly cadence with adoption data on the first slide.

These principles should be used as contract and governance checks. If the platform team cannot show how each principle is implemented and measured at the end of 90 days, the rollout should hold rather than expand.

06Preconditions Before Starting

Do not start this blueprint until each of the following is true. Starting without them predicts an adoption stall the blueprint cannot recover from.

• one named platform product manager with a written charter and dedicated capacity
• a target developer segment defined in writing (which teams, which services, which technology profile)
• one product engineering team willing to be the design partner for the first paved path
• an executive sponsor who has agreed to the primary adoption metric and its target for day 90
• funding for at least 2 platform engineers plus the product manager for at least 6 months
• a decision, per the Internal Developer Platforms buying guide, on which layer to build (developer portal, workload orchestrator, or bundled PaaS alternative) and, if a portal, which vendor

If any of these is missing, resolve it before Day 0. The rest of the blueprint assumes all are in place.

07Phase 1: Days 0 to 30 - Foundation

The goal of the first 30 days is to make the platform a product before it is a tool. No code needs to reach production in this phase. The output is a written foundation the rest of the rollout runs on.

Week 1 to 2: Charter and target segment

Write and circulate a one-page platform charter with:

• the target developer segment and the segments this platform is explicitly not for
• the top three developer pains the platform will address in the first 90 days
• the primary adoption metric and its 90-day target
• the platform product manager, platform tech lead, and executive sponsor by name
• the escape hatch: how a team gets an exception when the paved path does not fit

Circulate the charter to engineering leadership, security, and FinOps for written acknowledgment. Missing acknowledgment from any of these groups at this stage predicts rollout friction later.

Week 2 to 3: Paved path scope

Pick exactly one paved path to ship in the first 60 days. Recommended criteria:

• a workflow the target segment performs at least weekly
• an end-to-end path that includes provisioning, deploying, and observing at least one service
• a workflow that is currently painful enough that the design-partner team will invest time in the migration

Common first paved paths that work in practice:

• provision a new stateless service with database, secrets, and observability wired in
• deploy an existing service through a standardized CI or GitOps pipeline
• create a new environment for an existing service with policy and cost controls attached

Avoid catalog-first scoping (importing all services on day one) as the first paved path. A populated catalog with no paved path attached is a directory, not a platform.

Week 3 to 4: Data model and integrations

Model the minimum set of entities the paved path needs: services, teams, environments, and one resource type. Wire the platform to the existing CI, GitOps, and cloud provider using first-party integrations rather than custom code where possible. Document what the platform does not yet model so the escape hatch process handles those cases explicitly.

Phase 1 exit criteria

• charter circulated and acknowledged by engineering, security, and FinOps leadership
• paved path scope written with named design-partner team
• primary adoption metric defined with a day-90 target
• data model and first integrations working in a non-production environment
• weekly platform product review scheduled with adoption data as the first agenda item

If any exit criterion is missing at day 30, hold before Phase 2. Missing criteria at this gate typically become adoption blockers later that cost more to fix than the delay.

08Phase 2: Days 31 to 60 - First Paved Path in Production

The goal of the second 30 days is one paved path in production, used by at least two product teams, with the exception process working before the rollout expands.

Week 5 to 6: Paved path in a non-production environment

Ship the paved path end to end in a non-production environment with the design-partner team. Instrument the paved path from the start with:

• weekly active user counting (unique engineers, not unique sessions)
• funnel counters for each step in the paved path
• error and abandonment reasons at each step
• time from paved-path start to first successful outcome

Any paved path that ships without funnel instrumentation is untestable as a product and will not produce the data leadership needs at the 90-day gate.

Week 6 to 7: Second design-partner team

Bring on a second product team as a design partner. The second team is the first real test of whether the paved path generalizes; a paved path that works for team one and fails for team two is more common than teams expect and is better discovered at day 45 than at day 90.

Week 7 to 8: Exception process live

Document and staff the exception process before broad rollout, not after. Minimum working exception process:

• a documented submission path (form, ticket, or issue template) with fields for use case, blocker, and requested timeline
• a named triage owner on the platform team with a response service-level target
• three documented outcomes: paved-path update, one-off exception grant with expiry, or unsupported with reasoning
• an exception log queryable by the platform team and reviewed weekly

Missing an exception process at this stage produces shadow infrastructure within one quarter; product teams route around a paved path with no escape hatch before they route around the platform entirely.

Phase 2 exit criteria

• paved path shipped end to end and used by at least two product teams
• funnel and adoption instrumentation reporting weekly
• exception process live with at least one exception logged and resolved
• security and FinOps sign-off on the production data path
• one paved-path update shipped in place without regressing pilot services

If exit criteria are not met at day 60, hold rather than start Phase 3. Expansion on top of a broken paved path or a missing exception process is the most expensive form of rework in a platform rollout.

09Phase 3: Days 61 to 90 - Adoption and Expansion Decision

The goal of the final 30 days is to prove adoption on the first paved path before deciding whether to expand, hold, or reset.

Week 9 to 10: Adoption push and reporting

Roll the paved path out to the full target developer segment. Report weekly to leadership:

• weekly active platform users as a percentage of eligible engineers
• number of services using the paved path
• exception rate and resolution time
• funnel step drop-off rates and top abandonment reasons

Adoption pushes work best when the design-partner teams are visible and vocal internally. If neither design partner is willing to advocate for the paved path publicly by week 10, that is a stronger negative signal than any metric.

Week 10 to 11: Second paved path scoping

Only start scoping a second paved path once the first paved path is meeting or on track to meet its adoption target. Starting a second paved path before the first is proven produces two half-built paths and a stalled adoption metric.

Week 11 to 12: 90-day gate review

The 90-day gate is a go, hold, or reset decision made by the executive sponsor with the platform product manager and platform tech lead. The gate has three defensible outcomes:

• Go: adoption target met or on track; expand to a second paved path and a broader segment
• Hold: adoption below target but paved path and exception process are working; fix the adoption gap before adding scope
• Reset: adoption below target and paved path or exception process not working; revisit the layer decision, vendor choice, or target segment before continuing

A go decision without documented weekly active use is not a defensible go. A hold decision that becomes a permanent hold is a reset in denial; make the reset call explicitly if the hold extends past a second month without adoption movement.

Phase 3 exit criteria

• weekly active platform users as a percentage of eligible engineers reported for four consecutive weeks
• at least one paved path meeting or on track to meet its day-90 target
• exception process running with a documented service-level track record
• explicit go, hold, or reset decision recorded by the executive sponsor
• roadmap for the next 90 days written and circulated

10Golden Path Template Mechanics

Golden path templates that survive contact with production tend to share five properties. Templates missing any of them typically regress within two quarters.

1. Versioned: templates have a version, changelog, and deprecation policy just as any other production dependency does.
2. Updatable in place: a template update propagates to services created from the template without a manual copy-paste migration.
3. Reviewable: template changes go through code review by the platform team and, for policy-relevant changes, by security or FinOps.
4. Escape-hatched: every template has a documented path for a team to opt out of a specific component while remaining on the template for the rest.
5. Instrumented: template usage is counted per version so the platform team can see who is on which version and where migrations are stuck.

Templates that hardcode vendor-specific choices without a documented replacement path become the platform's own technical debt. A template that outlives its underlying vendor without a migration story is a source of future rollback pain.

11Adoption Instrumentation

Weekly active platform users as a percentage of eligible engineers is the primary adoption metric. Everything else is context.

Primary metric

Weekly active platform users divided by eligible engineers, reported weekly. Eligible engineers is defined in the charter and revisited every quarter as the target segment changes. A weekly active user is a unique engineer who took at least one non-read action in the platform in the past 7 days.

Secondary metrics

• number of services on the paved path divided by services in scope
• exception request rate per week and resolution time
• funnel step drop-off rates for the paved path
• template version distribution across services
• time from paved-path start to first successful outcome

Metrics to avoid reporting as adoption

• portal page views
• catalog entry count
• template run count without unique engineer counting
• Slack channel members
• documentation page views

Activity metrics predict nothing on their own. Adoption metrics tied to unique engineers doing platform work are the only defensible input to the 90-day gate decision.

12Exception Process Reference

An exception is a legitimate use case the paved path does not currently support. The exception process is not a queue of complaints; it is the primary feedback loop that tells the platform team what the paved path needs to model next.

Submission

Standard template with: use case description, current paved-path blocker, requested timeline, and business impact. Submissions without business impact are triaged as feature requests, not exceptions.

Triage

Weekly triage by the platform product manager and platform tech lead. Every exception receives one of three outcomes within a defined service-level target:

• Paved-path update: the paved path is updated to support the use case; the exception is closed once the update ships.
• One-off grant with expiry: the exception is granted with a defined expiry date, at which point the team must either be on the paved path or resubmit.
• Unsupported: the use case is out of scope; the team routes to a documented alternative with the reasoning recorded.

Review

Weekly exception log review by the platform product manager. Rising exception rate against a stable paved path is a signal that the paved path needs a version update. Falling exception rate against a growing service count is a signal that the paved path is generalizing correctly.

13Anti-Patterns During Rollout

These are execution-phase failure modes distinct from the strategic failure modes covered in the Internal Developer Platforms buying guide. Each has a specific rollout-phase signal.

Anti-pattern 1: Big-bang launch

Announcing the platform to the whole engineering organization on day 30 before any paved path is in production. The failure signal is a launch-week spike in portal traffic followed by four weeks of near-zero return use. Fix: launch to the design-partner team first, expand only after Phase 2 exit.

Anti-pattern 2: Feature parity chase

Building every capability the previous internal tooling had before shipping the first paved path. The failure signal is a Phase 1 that extends past day 45 with no production traffic. Fix: cut scope to one paved path; treat feature parity as a Day 90+ concern.

Anti-pattern 3: Activity metric substitution

Reporting portal views, catalog counts, or template runs to leadership as adoption. The failure signal is that leadership believes adoption is healthy while product teams report the platform is unused. Fix: report weekly active platform users as the primary metric from day 30.

Anti-pattern 4: Exception queue stall

Exception requests pile up because triage is not staffed, and product teams stop submitting them and route around the platform silently. The failure signal is a falling exception rate combined with a falling adoption rate. Fix: name a triage owner in Phase 2 with a written service-level target.

Anti-pattern 5: Second paved path too early

Scoping a second paved path before the first is proven, producing two half-built paths and diluted platform team capacity. The failure signal is neither paved path meeting its adoption target at day 90. Fix: enforce the Phase 3 rule that the first paved path must be on track before the second starts.

Anti-pattern 6: Template rot

Templates ship once, never updated, and diverge from the underlying infrastructure over 3 to 6 months until they produce more support load than they save. The failure signal is a rising rate of template-generated services requiring manual fixes after creation. Fix: require every paved path to include a template update cadence in its Phase 1 scope.

14Roles and Ownership

Ownership continuity through all three phases matters more than titles. Rollouts where the platform product manager or platform tech lead changes mid-blueprint typically restart Phase 1 whether they mean to or not.

15Phase Gate Decision Reference

The gates exist to make hold and reset defensible decisions rather than admissions of failure. Rollouts that treat every gate as a go decision by default produce the adoption stalls this blueprint is designed to prevent.

1690-Day Deliverables Checklist

By day 90 the platform team should be able to produce, on request:

• the platform charter with signatures from engineering, security, and FinOps
• the paved path in production with at least two product teams using it
• weekly active platform user reports for the last four weeks
• an exception log with at least one resolved exception and one paved-path update in place
• a roadmap for days 91 to 180 with the next paved path and target segment expansion
• a written go, hold, or reset decision from the executive sponsor

If any of these deliverables is missing at day 90, the rollout has not completed the blueprint, regardless of feature progress.

17Frequently Asked Questions

How long should the first paved path take to ship in production

The blueprint budgets 30 days for foundation and 30 days for the first paved path in production, so 60 days total from charter to production for the first paved path. Teams that ship faster typically had a working prototype before Phase 1 began. Teams that ship slower usually skipped the charter and target segment work and are pushing implementation before the product decisions are settled.

What if we cannot get an executive sponsor to commit to an adoption metric

Do not start the blueprint. A platform rollout without an agreed adoption metric will be judged retroactively on whichever metric leadership prefers at day 90, which typically favors activity metrics that look healthy but predict nothing. Resolve the sponsor commitment before Day 0.

Can we run this blueprint on Backstage self-hosted

Yes, but the timeline assumes the Backstage instance is already stable in a non-production environment before Day 0. Standing up self-hosted Backstage from scratch typically takes 3 to 6 months of platform team work on its own and is a separate project from the rollout described here. Managed Backstage or a commercial portal shortens the pre-Day-0 preparation to 2 to 4 weeks.

What happens if the second design-partner team rejects the paved path

Treat rejection as the intended output of Phase 2, not a failure. A paved path that works for the first team and fails for the second team is the primary signal Phase 2 is designed to produce. Update the paved path, extend Phase 2 by 2 to 3 weeks, and re-test with the second team before starting Phase 3.

How do we know when to reset rather than hold

Reset when either the paved path or the exception process is not working, not just when adoption is below target. A hold with a working paved path and a working exception process is a scoping problem the platform product manager can fix within one to two months. A hold with a broken paved path or a broken exception process is a rollout that needs its layer, vendor, or segment decisions revisited before more time is spent.

What is the right size for the platform team through the first 90 days

Two to five platform engineers plus one platform product manager plus fractional security and FinOps representation. Teams smaller than two engineers cannot cover the paved path implementation and the exception triage load simultaneously. Teams larger than five engineers before Phase 3 exit typically over-invest in feature breadth and under-invest in adoption work.

Should we report metrics to leadership before day 90

Yes, weekly starting at day 30. Leadership that first sees adoption metrics at the 90-day gate has no context for the go, hold, or reset decision. Weekly reporting from day 30 also creates the accountability loop that prevents activity metrics from being substituted for adoption metrics later.

What if leadership wants to expand to a second paved path before day 90

Push back with the Phase 3 rule: expansion depends on the first paved path meeting or on track to meet its adoption target. Expansion before the first paved path is proven is the single most common reason for the two-half-built-paths anti-pattern. If leadership overrides the rule, record it in the phase gate documentation so the outcome is attributable.

18Architecture Diagram: Rollout Loop

[Charter + target segment + primary metric]
              |
              v
   [Paved path scoped, data model, integrations]
              |
              v
   [Paved path in non-prod with design partner team 1]
              |
              v
   [Second design partner team adopts]
              |
              v
   [Exception process live, funnel reporting weekly]
              |
              v
   [Adoption push to full target segment]
              |
              v
   [90-day gate: go, hold, or reset]
              |
              v
   [Roadmap for next paved path or reset decision]

The loop continues past day 90. Every subsequent paved path runs through a compressed version of the same three phases with the exception process and adoption reporting already in place.

19External References

• CNCF Platforms White Paper
• CNCF Platform Engineering Maturity Model
• Puppet 2024 State of DevOps Report
• Team Topologies key concepts
• platformengineering.org guidance on failure modes

20Related Reading

• Internal Developer Platforms: A Decision Guide for Platform Teams
• Leading AI Engineering Service Providers
• Leading Application Modernization Partners
• Kubernetes Version Lifecycle Blueprint: 30/60/90 Plan for Safe Upgrades
• Methodology

21Limitations

This blueprint prescribes a 30/60/90 execution sequence for the first paved path of an internal developer platform. It does not replace the layer and vendor decisions covered in the pillar buying guide, nor does it address specialized rollouts such as regulated-industry compliance overlays or platform mergers after acquisition. Adoption benchmarks cited from third-party sources are directional and vary across organizations. Final decisions on scope, staffing, and gate criteria should be adjusted for organizational context and reviewed with security, FinOps, and executive stakeholders before Day 0.

Author: Mira Voss Reviewed by: StackAuthority Editorial Team Review cadence: Quarterly (90-day refresh cycle)