When do we need a platform team?

Roughly 30-50 engineers is when the coordination cost of everyone building their own pipelines and infra exceeds the cost of a dedicated 3-5 person platform team. Below that, a 'platform-minded' senior engineer with 20-30% of their time on shared infra is usually enough.

Backstage or build our own developer portal?

Start with Backstage. It's the default, has an active plugin ecosystem, and the setup effort is a fraction of building from scratch. Build your own only if you have specific requirements Backstage's model can't accommodate — rare in the first two years.

How do we know if the platform is worth the investment?

Compare team-reported time-to-production for new services before and after, and track engineer time spent on 'undifferentiated' work (env setup, pipeline debugging, on-call fatigue not caused by their own code). A well-run platform team of 4-5 engineers should return 2-3x its cost in reclaimed product-eng time within 18 months.

Platform Engineering: IDP, Golden Paths, Team Topology

Platform engineering is the discipline of building an internal product for your own developers — the pipelines, environments, templates.

Platform Engineering: Building an Internal Developer Platform That Product Teams Actually Use

Platform engineering formalizes what used to be a scattered set of DevOps scripts and tribal knowledge into an internal product with a roadmap, a team, and measured user satisfaction. The unit of delivery is the Internal Developer Platform (IDP): a curated set of self-service capabilities — provisioning environments, running CI/CD, observing services, managing secrets, deploying to production — offered through a coherent interface. The premise is that most product teams do not want to become experts in Kubernetes, IAM, and OpenTelemetry; they want to ship features safely. Platform engineering turns that want into a product.

Golden paths, not gilded cages

A golden path is the platform team's opinionated, well-supported way to accomplish a common task — 'create a new service,' 'add a scheduled job,' 'expose a public API.' Golden paths are optional but so much easier than the alternative that most teams take them. They should include: a template repo with CI/CD wired, observability instrumentation baked in, security scanning enabled, deployment to staging on merge, and one-command deploy to production. When teams need to deviate (because the golden path doesn't fit their case), they can — but they take on the operational burden they were previously offloading. Cages, by contrast, force everyone through a single path regardless of fit, and drive high-agency teams to route around the platform entirely.

Team Topologies as a starting frame

The Team Topologies model (Skelton & Pais) maps well: stream-aligned teams (product) consume from platform teams via well-defined interfaces; enabling teams help stream-aligned teams adopt new capabilities; complicated-subsystem teams own specialized components (e.g., the ML training platform). Practical implication: your platform team should have PMs, not just senior engineers. The PM's job is to talk to internal developers, prioritize the roadmap, and say no to bespoke requests that would fragment the platform. Without this discipline, platform teams turn into ticket-taking helpdesks.

What to build first

Sequence matters. Common ordering: (1) A single opinionated CI/CD pipeline that every service uses. (2) A service catalog (Backstage or homegrown) that answers 'what services exist, who owns them, how do I contact on-call.' (3) Standardized environments (dev, staging, prod) provisioned via IaC modules teams consume. (4) Observability primitives (logs, metrics, traces) auto-wired via SDK/sidecar so teams don't hand-instrument. (5) Secrets management with a self-service UI. (6) A developer portal that ties it all together. Skip ahead only when a specific pain (e.g., feature flags, cost visibility) is dominant.

Adoption metrics that keep the team honest

Vanity: number of services on the platform, number of pipelines executed. Real: (a) lead time for new service — time from 'I need a new service' to 'it's serving traffic in production' — target under 1 day. (b) developer satisfaction (quarterly survey, NPS or similar, segmented by tenure). (c) platform-caused incidents per quarter (an incident where the platform was the root cause). (d) golden-path adoption rate for new services (target >80%). (e) time-to-fix for platform-reported bugs. Report these to engineering leadership monthly and use them to prioritize the roadmap.

Anti-patterns

(1) Building the platform for the platform team's aesthetic satisfaction rather than for user problems — the pretty Kubernetes operator no team asked for. (2) Mandating the platform via edict rather than earning adoption via usefulness — creates malicious compliance and shadow infrastructure. (3) Treating the platform as a cost center rather than a product — no PM, no roadmap, no user research, features shipped based on senior engineer intuition. (4) Coupling too tightly to a specific vendor (a single cloud, a single CI tool) — makes future migrations existential rather than expensive. (5) Ignoring the migration path — new services onboard easily, but the ten highest-value existing services never migrate because it's too painful.

Frequently asked questions

When do we need a platform team?: Roughly 30-50 engineers is when the coordination cost of everyone building their own pipelines and infra exceeds the cost of a dedicated 3-5 person platform team. Below that, a 'platform-minded' senior engineer with 20-30% of their time on shared infra is usually enough.
Backstage or build our own developer portal?: Start with Backstage. It's the default, has an active plugin ecosystem, and the setup effort is a fraction of building from scratch. Build your own only if you have specific requirements Backstage's model can't accommodate — rare in the first two years.
How do we know if the platform is worth the investment?: Compare team-reported time-to-production for new services before and after, and track engineer time spent on 'undifferentiated' work (env setup, pipeline debugging, on-call fatigue not caused by their own code). A well-run platform team of 4-5 engineers should return 2-3x its cost in reclaimed product-eng time within 18 months.

Related fundraising guides (40)

Investor directory · Fundraising library · Articles A–Z · Company funding database