---
title: "internal developer platforms | Skills We Assign For | Azendo"
description: "Internal developer platforms — paved paths, golden templates, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/internal-developer-platforms/"
---

[Skills](https://azendo.co/skills/) Cloud and infrastructure 

# internal developer platforms.

An internal developer platform is the layer that lets product teams deploy, run and observe services without needing to understand the infrastructure beneath. It packages the organisation's standards into paved paths rather than documents.

## Where internal developer platforms fits on a long engagement.

The measure of a platform is whether the easy path is the correct path. If deploying properly — with monitoring, sensible defaults and least-privilege permissions — takes longer than deploying badly, teams will deploy badly under deadline, and no amount of documentation changes that arithmetic.

The characteristic failure is a platform built for the platform team's idea of the problem. Product teams route around abstractions that do not fit their actual needs, and the organisation ends up with both a platform and the bespoke setups it was meant to replace. Treating product teams as users, with the research that implies, is what separates the two outcomes.

## What an assigned team does with internal developer platforms.

A platform is a product with internal customers, and it needs the same things any product does: a roadmap, feedback, support and someone accountable for adoption. Treated as a project with an end date, it ships and then rots.

That ongoing product responsibility is what standing capacity provides, and how it is agreed is set out in [how the monthly fee is built](https://azendo.co/pricing/).

## What we use internal developer platforms for.

* The correct path made the fastest one Monitoring, permissions and defaults included by default, so doing it right is not slower.
* Golden templates for new services A scaffold that produces a compliant service, rather than a document describing one.
* Adoption measured rather than assumed Tracking what teams actually use, so abstractions that do not fit get fixed.

## How internal developer platforms capacity is assigned.

Platform engineering capacity is assigned under [devops as a service](https://azendo.co/services/cloud-and-devops/), treated as an ongoing product rather than a delivery project.

## Roles we assign internal developer platforms for

* [Platform Engineer Cloud and DevOps](https://azendo.co/services/cloud-and-devops/platform-engineer/)

## Service lines it sits in

* [Cloud and DevOps](https://azendo.co/services/cloud-and-devops/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in cloud and infrastructure

* [Kubernetes — skill we assign for](https://azendo.co/skills/kubernetes/)
* [Docker — skill we assign for](https://azendo.co/skills/docker/)
* [Terraform — skill we assign for](https://azendo.co/skills/terraform/)
* [AWS — skill we assign for](https://azendo.co/skills/aws/)
* [Azure — skill we assign for](https://azendo.co/skills/azure/)
* [GCP — skill we assign for](https://azendo.co/skills/gcp/)
* [Terraform modules — skill we assign for](https://azendo.co/skills/terraform-modules/)
* [Pulumi — skill we assign for](https://azendo.co/skills/pulumi/)

## Tell us what your roadmap needs internal developer platforms for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)