Internal Developer Platform Starter. @developer-platform-starter

Before platform engineering, every new service means tickets: one for the repo, one for the pipeline, one for environments, one for access — days of waiting wrapped around minutes of work. The Internal Developer Platform Starter builds the first real platform layer on your existing cloud and tooling: golden paths for the common cases, self-service where tickets used to be, and paved-road defaults for deployment and operations.

This is deliberately a starter, not a platform program: scoped to the highest-friction workflows, built on tools you already run rather than a new estate to operate. The finish state is measurable — a developer takes a new service from nothing to deployed-in-an-environment through self-service alone, and the baseline ticket load drops accordingly.

Self-Service Provisioning

Templated creation of services, repos, pipelines, and cloud resources — requestable by developers, executed by automation, governed by defaults your platform and security owners set.

Environment Management

Consistent, reproducible environments — creation, configuration, and teardown — so environment drift and shared-environment contention stop taxing delivery.

Standardized Deployment

A paved-road deployment path with the safety rails built in — reviews, gates, rollback — that teams adopt because it is easier than their custom path, not because it is mandated.

Operational Baseline

Logging, metrics, and alerting wired in by default for platform-created services, with ownership metadata attached from birth.

1. Scope — Measure current friction — ticket volumes, lead times, tool sprawl — and pick the golden paths that remove the most of it.
2. Build — Build provisioning, environments, and the deployment path; onboard two or three real teams as first users.
3. Handover — Hand the platform to its owning team with runbooks, contribution docs, and the friction metrics baseline for the roadmap.

The Internal Developer Platform Starter is a menu item on the Scrums.com delivery catalog, available at every plan tier. Add it to your plan backlog and your delivery team schedules it like any other item — scoped, tracked, and reported through the SEOP. See Delivery Plan Tiers.

Do we need Backstage or a portal product?

Not to start. The starter favors automating your existing tools over installing new ones; a portal earns its place later if the catalog and path count justify it. Scoping makes that call with evidence.

How big a team does this make sense for?

Typically from around 15–20 engineers upward, when informal knowledge stops scaling and ticket queues appear. Below that, the Environment Standardization Package or CI/CD Pipeline Implementation usually fixes the actual pain for less.

What follows the starter?

Whatever the metrics point to — commonly the Golden Path Service Template to deepen the paved road, or the Service Catalog Implementation once service count makes discovery the problem.