Building an Internal Developer Platform

An internal developer platform (IDP) is the infrastructure layer a platform team builds so that following the compliant, secure, well-tested way of doing something is also the fastest way. It is not a single tool — it is the self-service catalog, provisioning APIs, and golden-path templates that sit between “an engineer has an idea” and “that idea is running in production with the right guardrails attached.” At Scutiger, we build this layer for clients whose engineering organization has outgrown tribal knowledge.

Key Takeaways

• A platform is infrastructure for building infrastructure. It does not ship features directly; it makes every team that does ship features faster and more consistent.
• Self-service beats tickets. If provisioning a new service, database, or environment requires a request to the platform team, the platform has not actually removed the bottleneck — it has just centralized it.
• Golden paths need a home. A template that lives in a wiki page gets stale. A template that lives in a scaffolding tool the platform enforces stays current.
• The platform team’s customer is the product engineer, not the executive who approved the budget. A platform nobody adopts voluntarily has failed regardless of how well-architected it is.

Why Teams Outgrow Tribal Knowledge

This is a different problem from the two-lane model that governs how individual prototypes move to production — a platform is the infrastructure layer underneath both lanes, not a replacement for either.

In a five-person engineering team, there is no need for a platform. Everyone knows how deployments work because everyone was in the room when the deployment pipeline was built. Onboarding a new engineer means pairing with someone for a week.

That model breaks down as teams multiply. By the time an organization has six or seven product teams, each one has usually solved the same problems — service scaffolding, secrets management, observability wiring — slightly differently. New engineers inherit whichever team’s conventions they land on. Cross-team moves become retraining events. And nobody owns making the “boring” infrastructure work reliably, because it is everyone’s second priority.

An internal developer platform exists to make that infrastructure someone’s first priority, and to make the result available to every team without a ticket queue in between.

What We Actually Build

The self-service catalog

A catalog is the front door: a list of things a product engineer can provision without waiting on the platform team — a new service repository, a database instance, a queue, a staging environment. Each catalog entry is backed by a golden path template, so provisioning a resource and getting it configured correctly are the same action, not two separate steps a developer can forget between.

Golden path templates

Each template encodes a decision the platform team made once so individual engineers do not have to make it again: which base image to use, how secrets are injected, what the default resource limits are, which observability hooks are wired in automatically. A new service created from a golden path template starts with logging, tracing, and health checks already working — not as a follow-up task.

The provisioning layer

Templates need somewhere to run. We typically build this as a thin API over existing infrastructure-as-code tooling — Terraform, Pulumi, or a cloud provider’s native APIs — so “create a new service” is a single API call or CLI command, not a multi-step runbook a developer has to execute by hand and inevitably gets slightly wrong under time pressure.

Golden path governance

Templates drift if nobody owns updating them. We set up a lightweight ownership model: the platform team (often two to four engineers, even at a mid-sized company) reviews and versions templates, and services built from an older template version get a visible signal — not a blocking gate — that a newer, better-supported path exists.

A Worked Example: Standing Up a New Service

Consider a product team that needs a new backend service. Without a platform, this typically means: create a repository, copy configuration from a similar service and hope it is current, manually wire up CI/CD, request database credentials from whoever manages the database, configure logging by copying a snippet from Slack, and eventually — often days later — deploy to a staging environment to see if any of it worked.

With a platform, the same task looks like: run platform create service --template=api-service, which scaffolds the repository from the current golden path, provisions a staging database with credentials injected via the platform’s secrets manager, and wires CI/CD to the platform’s shared pipeline. The engineer’s first commit is business logic, not plumbing.

The time saved is real, but the more important effect is consistency: every service created this way starts with the same security posture, the same observability, and the same deployment pipeline — which is what makes fleet-wide changes (a new compliance requirement, a security patch) possible to roll out centrally instead of chasing down every team’s bespoke setup.

Comparing the Two Models

	Without a platform	With an internal developer platform
New service setup	Hours to days, copied from an existing service	Minutes, from a maintained template
Security posture	Varies by which engineer built it and when	Consistent, set once in the golden path
Onboarding a new engineer	Pairing and tribal knowledge, roughly a week	Self-service catalog plus documentation
Rolling out a fleet-wide change	Chasing down every team’s bespoke setup	Update the template, flag outdated services
Platform team’s role	Reactive — answering tickets	Proactive — maintaining paved roads

Limitations

A platform is an investment with a payback period, not an instant win. Building the first two or three golden paths well takes real engineering time — usually a dedicated platform engineer or small team for a quarter or more before the catalog is useful enough that product teams adopt it voluntarily. For a very small organization, or one with only one or two product teams, that investment does not pay back; the tribal-knowledge model is still cheaper. And a platform that is mandated rather than adopted — where engineers are forced onto a golden path that is slower or less flexible than what they had before — creates resentment instead of leverage. Adoption has to be earned by the platform actually being the fastest path, not assumed because it exists.

Bottom Line

An internal developer platform is not a product you buy — it is the paved-road infrastructure a platform team builds and maintains so that the compliant, well-observed, secure way of shipping software is also the easiest way. It pays off once an organization has enough product teams that tribal knowledge no longer scales, and it fails when it is imposed rather than adopted. We build the self-service catalog, golden path templates, and provisioning layer as a foundation clients’ own platform teams keep evolving after our engagement ends — see how this connects to guardrails over gates for the governance side of the same problem, MLOps: closing the gap between notebook and production for how this platform layer applies specifically to machine learning systems, or our approach for how platform work fits into a full engagement.