Ask five engineering leaders how to start building an internal platform and you will get five budgets, five tool shortlists and one shared blind spot: sequencing. The organisations that succeed do not buy differently — they order the work differently. This guide lays out a 90-day build plan for PlatformOps and platform engineering that has become close to a de facto pattern across the industry, with the checkpoints you can audit at each phase.
First, define what PlatformOps builds by day 90
You are not building a portal, a reorganisation or a purchase order. You are building exactly one thing by day 90: a single golden path — an opinionated route that takes a team from an empty repository to a running, monitored, policy-compliant service without filing a single ticket. Everything else (catalogues, scorecards, fancy dashboards) is deferred deliberately.
Restraint is the strategy here, not a compromise. The Team Topologies crowd use the phrase “thinnest viable platform” for this discipline: supply the smallest set of capabilities that removes real toil, and resist adding layers nobody asked for. A thin platform that teams actually finish adopting beats an ambitious one that stalls at 30% usage and consumes its own goodwill.
Days 1–30: evidence gathering
The first month produces no code, and that is the point. Two workstreams run in parallel.
Workstream A: interview five teams
Pick five product teams that differ in size, criticality and temperament. For each, gather the same evidence:
- Where does their delivery friction concentrate? Ask for the last three delays and trace causes, not opinions.
- What do they rebuild that another team has already built? Pipelines, deployment scripts, alerting, environment setup are the usual suspects.
- What would they refuse to hand over? Every organisation has parts of the stack teams treat as identity. Knowing this early prevents a doomed design.
Five interviews is not folklore — it is enough to separate shared pain from local habit, and small enough to actually complete. Write the findings into a two-page summary that names the top repeated costs in hours per fortnight.
Workstream B: inventory what exists
Most “we need a platform” announcements underestimate how much capability already lies scattered across the organisation. Catalogue every pipeline, template, internal library and runbook that exists today, with an owner against each. The inventory routinely changes the plan: some of what you intended to build turns out to exist twice, badly, and consolidation becomes the first win instead of greenfield construction.
Close the month with a charter — one page, signed by an executive sponsor — that states which pain the platform attacks first, what success looks like numerically, and what is explicitly out of scope. If you cannot get the signature, stop here; an unfunded platform is a slow-motion morale problem.
Days 31–60: one path, one design partner
Month two is where most initiatives go wrong, because they widen instead of deepening. The discipline is a single golden path, developed with exactly one design partner team.
- Choose the design partner deliberately. Not the most enthusiastic team and not the most hostile — the one whose delivery pattern is typical, so lessons generalise. Agree on the trade: they get first access and direct influence; you get unfiltered feedback and the right to ship breaking changes during the pilot.
- Cover the full route, thinly. Repo scaffolding, pipeline, environment, deploy, basic monitoring. Skip everything a team can reasonably do itself. Every extra feature added now must displace something, or the path becomes a maze.
- Ship weekly to the design partner. Adoption friction discovered in week five is cheap; discovered after general availability, it is rumour.
- Instrument the path from day one. Record how long the first deployment takes a newcomer, and how often the path breaks mid-journey. You will need the baseline in month three, and you cannot recover it retrospectively.
Aim to exit the month with the design partner shipping real work through the path daily — not a demo, not a side project. That single fact does more for internal credibility than any presentation.
Days 61–90: beta, GA and the boring paperwork
The final month converts a promising pilot into an operated service. The sequence matters:
- Beta with a second and third team. Two to three teams, chosen from your original interview pool. Their job is to break your assumptions: the path that felt obvious to the design partner will confuse somebody, and you want that discovered now.
- Publish the runbook and the support model. Who answers when the path fails at 2 a.m.? Which components carry what service levels? Write it down before general availability, because after GA the questions arrive faster than the documentation.
- Declare the lifecycle policy. Every component gets a stage — proposed, alpha, beta, generally available, deprecated, retired — and rules for moving between stages. The policy sounds bureaucratic until the first dependency change, when it becomes the difference between orderly migration and silent breakage.
- Run your first deprecation. Retire something genuinely: an old script, a legacy pipeline, a duplicated template. Announce it, help consumers move, switch it off. A platform team that has never retired anything is a platform team that accumulates permanent clutter — and everyone watching will have noticed.
The evidence: did the PlatformOps rollout work?
Analytical teams commit to numbers before the rollout starts. Two suffice for the first quarter:
- Time to first deployment. Measure the median across the beta teams against your month-two baseline. A credible outcome is measured in multiples, not percentages — new services reaching production in a day rather than a fortnight.
- Off-path rate. The share of deployments that bypass the golden path. It will never be zero, and it should not be: teams keep the right to leave the path when they outgrow it, they just accept the support consequences. A falling trend tells you the path fits; a rising one is design feedback, not disobedience.
If your organisation runs DORA’s four delivery measures, map the rollout onto that scorecard rather than inventing a parallel dashboard — the delivery data and the platform data should agree, and disagreement is itself diagnostic.
What stays deferred beyond day 90
Equally important is the list of things this plan deliberately postpones, because pulling them forward is how thin platforms become fat ones:
- Portal UIs and catalogues. With one golden path, a well-written wiki page listing the steps is often enough. Build the searchable front-end only when the number of paths makes finding things genuinely hard.
- Multi-cloud abstraction. Supporting a second cloud before the first one runs well doubles every design conversation for a benefit most teams never feel.
- Scorecards and league tables. Team-versus-team comparisons poison the voluntary goodwill the whole approach depends on. Publish aggregate numbers instead.
- A second golden path. Prove the first one can be operated, deprecated and improved through a full lifecycle before branching. The second path inherits the operating habits of the first — or inherits its chaos.
Quarter two can revisit all four, now with adoption data to justify each. The discipline of deferral is what separates PlatformOps teams that compound their gains from those that spend year one rebuilding the plan.
Three failure points to pre-empt
- Widening early. Under pressure to show progress, month-two teams build three paths badly instead of one well. Hold the line: depth first, breadth later.
- Skipping the boring paperwork. Runbooks and lifecycle policies feel like overhead until the first pager night proves otherwise. Schedule them in the plan; unscheduled, they never happen.
- Announcing before piloting. A general-availability announcement that precedes real usage creates expectations the platform cannot honour. Let the design partner’s results make the announcement for you.
For teams that want the wider context before committing to this sequence — where the practice stands, what a reference architecture looks like, and how the vocabulary fits together — a good single starting point is the platform engineering reference in the Ops Atlas.
And because the platform’s first users are engineers who need their own grounding, our guide to SRE training and core principles covers the reliability half of the skill set, while this piece on scalable digital product development frames the growth pressures that make shared platforms worth funding in the first place.
Ninety days is not a magic number; it is a forcing function. Long enough to build something real, short enough that enthusiasm and executive attention survive the journey. Run the plan as written, audit each phase against its checkpoints, and by the end of the quarter you will own either a working PlatformOps foundation with evidence attached — or a documented list of organisational blockers that needed solving anyway.
