Platform engineering is the discipline of building internal developer platforms that make teams productive without sacrificing governance. A good platform reduces the time from "I have an idea" to "it is running in production" from weeks to hours. This guide covers platform design principles, golden path implementation, self-service infrastructure patterns, template catalogs, and measuring developer experience.
Gartner predicts that by 2027, 80% of software engineering organizations will have platform teams, up from 45% in 2024. Puppet's 2026 State of DevOps report found that teams with internal developer platforms deploy 30x more frequently and have 60% lower change failure rates compared to teams without platforms.
---
What is an Internal Developer Platform
An Internal Developer Platform (IDP) is a self-service layer on top of your infrastructure that abstracts complexity while maintaining standards. It answers the question: "How do I get my code to production without filing a ticket?"
Platform Capabilities Maturity Model
| Level | Capability | Example |
| 1 - Manual | Ticket-based provisioning | "File a Jira ticket for a new service" |
| 2 - Scripted | Runbook-driven | "Run this script to create a service" |
| 3 - Self-Service | UI/CLI provisioning | "Click to create a new service" |
| 4 - Automated | Template-driven with guardrails | "Choose a template, deploy automatically" |
| 5 - Intelligent | AI-assisted with recommendations | "Platform suggests optimal config" |
Most organizations should target Level 3-4. Level 5 is emerging and not yet proven at scale.
---
Golden Paths
A golden path is the recommended, supported, and easiest way to accomplish a common task. It is not a mandate but a strong default that covers 80% of use cases.
Example Golden Paths
<h1>golden-paths/web-service.yaml</h1>
name: Web Service (Node.js)
description: "Standard web service with API, database, and monitoring"
includes:
- runtime: node:20-alpine
- framework: fastify (or express)
- database: postgresql (managed)
- cache: redis (managed)
- ci_cd: github_actions
- deployment: docker + arxentra_vps
- monitoring: prometheus + grafana
- logging: structured_json
- testing: vitest + playwright
- documentation: openapi_3.1
provisioning_time: "15 minutes"
team_support: "platform-team Slack channel"
<h1>What this golden path provides:</h1>
<h1>1. Scaffolded project with tests, CI/CD, Dockerfile</h1>
<h1>2. Managed PostgreSQL instance connected</h1>
<h1>3. Redis cache provisioned</h1>
<h1>4. Monitoring dashboard pre-configured</h1>
<h1>5. Deployment pipeline ready (push to main = deploy)</h1>
<h1>6. Runbook template with incident procedures</h1>
Golden Path vs Mandate
| Aspect | Golden Path | Mandate |
| Choice | Recommended, not required | Required, no exceptions |
| Flexibility | Teams can deviate with justification | No deviation |
| Support | Full support on the golden path | Support regardless |
| Innovation | Teams can experiment | Innovation stifled |
| Adoption | 80%+ voluntary adoption | 100% forced compliance |
The goal is making the golden path so easy and well-supported that teams choose it voluntarily. If a team needs to deviate, they accept responsibility for their own support.
---
Self-Service Infrastructure
Developers should provision infrastructure without waiting for another team.
Service Catalog
The example below is an internal catalog your platform team defines and maintains. The offerings, sizes and inclusions are illustrative, not a list of any provider's products.
<h1>service-catalog/offerings.yaml (your internal platform catalog - example)</h1>
offerings:
- name: VPS Instance
provisioning_time: 2 minutes
sizes: [starter, basic, standard, performance, pro]
includes: [monitoring, backups, ssh_access]
request_method: cli_or_ui
- name: Managed PostgreSQL
provisioning_time: 5 minutes
sizes: [standard, ha, ha_with_replicas]
includes: [automated_backups, pitr, monitoring]
request_method: cli_or_ui
- name: Redis Cache
provisioning_time: 2 minutes
sizes: [256mb, 512mb, 1gb, 2gb]
includes: [persistence, monitoring]
request_method: cli_or_ui
- name: Object Storage Bucket
provisioning_time: 1 minute
access: s3_compatible_api
includes: [versioning, lifecycle_policies]
request_method: cli_or_ui
- name: Domain + SSL
provisioning_time: 5 minutes
includes: [auto_renewal, dns_management]
request_method: cli_or_ui
If you build this catalog on Arxentra, what it can back today is app services with usage-based vCPU/RAM sizing, plus single-instance managed PostgreSQL, MongoDB and Redis attached to a service. Arxentra does not provide HA databases, read replicas, automated backups/PITR or object storage, so those entries need your own tooling or a third party. See Services Overview for available services and Pricing for costs.
---
Template Catalog
Templates reduce the time to scaffold a new project from days to minutes.
Template Structure
<h1>Template directory structure</h1>
templates/
web-api-nodejs/
cookiecutter.json # Template variables
{{project_name}}/
Dockerfile
docker-compose.yml
package.json
src/
server.js
routes/
middleware/
tests/
.github/workflows/deploy.yml
monitoring/
dashboard.json # Pre-built Grafana dashboard
alerts.yml # Pre-configured alert rules
docs/
runbook.md # Incident response template
api.md # API documentation template
web-api-python/
# Same structure for FastAPI
static-site/
# Same structure for React/Next.js
background-worker/
# Same structure for queue processors
<h1>Create a new service from template</h1>
cookiecutter templates/web-api-nodejs
<h1>Prompts: project_name, database (postgres/none), cache (redis/none)</h1>
<h1>Output: fully scaffolded project ready to deploy</h1>
---
Measuring Developer Experience
What gets measured gets improved. Track these metrics quarterly.
| Metric | Definition | Target | How to Measure |
| Onboarding time | New hire to first production deploy | < 3 days | Survey new hires |
| Time to provision | Request to running infrastructure | < 15 minutes | Platform logs |
| Deploy frequency | Deploys per developer per week | > 5 | CI/CD metrics |
| Developer satisfaction | "How easy is it to deploy?" (1-10) | > 8 | Quarterly survey |
| Cognitive load | Number of tools/systems to understand | < 5 | Platform audit |
| Support tickets | Infra-related tickets per sprint | < 2 per team | Ticket system |
| Golden path adoption | % of services on golden path | > 80% | Platform audit |
Developer Experience Survey Questions
---
Building the Platform Team
The platform team builds and maintains the internal developer platform. Treat other engineering teams as customers.
Team Structure
| Team Size (Total Eng) | Platform Team Size | Ratio |
| 10-25 | 1-2 | 10-15% |
| 25-50 | 2-4 | 8-10% |
| 50-100 | 4-8 | 6-8% |
| 100+ | 8-15 | 5-8% |
Platform Team Principles
---
Frequently Asked Questions
When should a company start investing in platform engineering?
When infrastructure management becomes a bottleneck for feature delivery, typically at 15-25 engineers. Before that, a well-documented set of scripts and runbooks is sufficient. The trigger is when multiple teams are solving the same infrastructure problems independently.
How is platform engineering different from DevOps?
DevOps is a culture and set of practices. Platform engineering is a discipline that builds products (platforms) to implement DevOps at scale. A DevOps engineer might write a deployment script. A platform engineer builds a self-service deployment system that all teams use.
What tools should I use to build an internal developer platform?
Start with what you have. A service catalog can be a well-organized GitHub repository with templates. Self-service provisioning can be a CLI tool that wraps Terraform. Only adopt purpose-built platform tools (Backstage, Port, Kratix) when your needs outgrow scripts and templates. See Cloud Computing for managed infrastructure that simplifies platform building.
How do I get buy-in from developers for the platform?
Solve their biggest pain point first. If deployments are slow, make them fast. If provisioning takes days, make it take minutes. Early wins build trust. Never mandate platform usage - make it so good that teams adopt voluntarily.
What is the biggest mistake platform teams make?
Building a platform nobody asked for. Always start with developer interviews and pain point analysis. Build the minimum viable platform that solves the top 3 pain points, then iterate. Avoid building a "complete platform" upfront - it will miss the mark. Contact Arxentra for platform engineering consultation.