You are forming a platform team of four to serve twelve product teams. What do you build first?

Not a platform. One golden path.

Four people cannot build an internal developer platform for twelve teams. They can make one journey excellent, and expand from evidence.

Choose the journey by measuring friction

Time three things across a few teams: how long to create a new service and get it to production, how long a routine deployment takes end to end, and how long to get a working development environment.

Whichever is worst is where you start. It is frequently the third and almost never the one the platform team assumed.

Build the path, not the components

For the chosen journey, make every step have a supported answer, wired together: the template, the pipeline, the observability, the secrets, the ownership record. A collection of good components with gaps between them is not a path, and the gaps are where teams fall off.

Adopt with two willing teams

Not a mandate. Two teams who want it, worked with directly, whose experience becomes the reference. Measure time-to-first-deploy before and after, because that number is your funding argument for everything that follows.

Buy or adopt everything else

CI execution, artifact storage, secret management, observability backends, the container runtime. Building any of them with four people is a commitment to a problem someone else has solved better. The glue is what you build, because it encodes your conventions and no product knows them.

What to instrument from day one

Where teams stall in the journey, which defaults they override, which documentation pages are opened during incidents. Platform teams are unusually prone to building from intuition, and the loudest voice nearby is not representative.

The trap to avoid

Building for the estate you imagine. Build for the two teams in front of you and let the third tell you what is missing.