Platform teams have emerged as the answer to scaling DevOps practices. Instead of every team figuring out Kubernetes, CI/CD, and observability independently, a platform team provides these capabilities as a service.
But internal platforms fail when they’re built like infrastructure projects instead of products. Here’s how to build platforms developers actually want to use.
Platform Philosophy
Product Mindset
Your developers are your customers:
Infrastructure thinking:
- “Here’s how to configure Kubernetes”
- “Read the documentation”
- “That’s not supported”
Product thinking:
- “How can we make deployment effortless?”
- “What friction are developers experiencing?”
- “How do we measure developer productivity?”
Self-Service First
Developers shouldn’t need to ask for help:
# Developer creates a file, platform handles the rest
apiVersion: platform.company.io/v1
kind: Application
metadata:
name: order-service
spec:
team: orders
runtime: node-18
replicas: 3
resources:
memory: 512Mi
cpu: 200m
ingress:
path: /api/orders
Ticket-based provisioning doesn’t scale.
Golden Paths, Not Golden Cages
Provide easy defaults, allow escape hatches:
Golden Path:
"Create service with standard template"
→ Works for 80% of cases
→ Zero configuration
→ Built-in best practices
Escape Hatch:
"Custom configuration needed"
→ Possible but requires justification
→ Still supported
→ Documentation available
Force developers onto the platform by making it better, not by mandating it.
Core Capabilities
Application Delivery
What developers need:
- Deploy code to production
- Roll back if problems
- Multiple environments
- Feature flags
Platform provides:
# Simple deployment
kind: Deployment
spec:
source:
github: org/repo
branch: main
environments:
- staging
- production
strategy:
canary:
percentage: 10
duration: 30m
One commit to deploy. One click to rollback.
Infrastructure as Code
What developers need:
- Databases
- Caches
- Message queues
- Storage
Platform provides:
# Developer requests database
kind: Database
metadata:
name: orders-db
spec:
type: postgresql
version: "14"
size: small
backup:
enabled: true
retention: 7d
Platform team handles:
- Provisioning
- Backups
- Monitoring
- Security
- Updates
Observability
What developers need:
- Know if their service is working
- Debug problems quickly
- Understand performance
Platform provides:
- Automatic instrumentation: Metrics without code changes
- Dashboards per service: Pre-built, customizable
- Distributed tracing: Across service boundaries
- Log aggregation: Searchable, correlated
- Alerting: SLO-based, actionable
Security
What developers need:
- Secure by default
- Compliance without effort
- Security scanning
Platform provides:
- Container scanning: Vulnerabilities caught in CI
- Secret management: Injected securely
- Network policies: Default deny
- RBAC: Automatic based on team
Building the Platform
Start with Pain Points
Interview developers:
- “What takes too long?”
- “What do you avoid doing?”
- “Where do you copy-paste?”
- “What breaks often?”
Build for actual pain, not theoretical problems.
Build Incrementally
Phase 1: CI/CD
- Standardize pipelines
- Automatic testing
- Deployment automation
Phase 2: Infrastructure
- Database provisioning
- Service discovery
- Configuration management
Phase 3: Observability
- Centralized logging
- Metrics collection
- Distributed tracing
Phase 4: Self-Service
- Developer portal
- Service catalog
- Documentation
Eat Your Own Cooking
Platform team uses the platform:
- Deploy platform services using the platform
- Experience the same friction developers do
- Prioritize based on personal pain
Measure Adoption and Satisfaction
Adoption metrics:
- Percentage of services on platform
- New service onboarding rate
- Feature utilization
Developer satisfaction:
- Developer surveys (NPS)
- Time to deploy
- Incident frequency
- Support ticket volume
Build a Developer Portal
Central hub for platform capabilities:
Developer Portal
├── Service Catalog
│ └── Create new service
│ └── Browse existing services
├── Documentation
│ └── Getting started
│ └── How-to guides
├── Service Status
│ └── Health dashboards
│ └── Recent deployments
└── Support
└── FAQs
└── Request help
Backstage is a popular option for building developer portals.
Team Structure
Platform Team Skills
Infrastructure:
- Kubernetes
- Cloud providers
- Networking
- Security
Software engineering:
- API design
- Backend development
- Tooling
Product:
- Developer experience
- Prioritization
- Stakeholder management
Collaboration Model
Not: Platform team builds everything in isolation
Instead:
- Embed with product teams periodically
- Gather continuous feedback
- Co-develop features with early adopters
- Rotate engineers between platform and product
Support Model
Tier 1: Self-service (documentation, portal) Tier 2: Slack channel, office hours Tier 3: Dedicated support for complex issues
Measure support volume. Reduce through better self-service.
Common Mistakes
Building Without Users
“We’ll build the perfect platform, then teams will use it.”
Reality: Build with users. Ship incrementally. Iterate based on feedback.
Too Much Abstraction
“Developers don’t need to know about Kubernetes.”
Reality: Some abstraction helps, too much hinders. Developers need mental models.
Mandating Without Value
“All teams must use the platform by Q3.”
Reality: Mandates create resentment. Make the platform so good teams choose it.
Ignoring Existing Workflows
“Teams should change their workflow to fit our platform.”
Reality: Meet developers where they are. Integrate with existing tools.
One Size Fits All
“All services use the same configuration.”
Reality: Different services have different needs. Provide sensible defaults with customization.
Migration Strategy
Strangler Pattern
New services use the platform. Existing services migrate gradually:
Month 1-3: Platform MVP with new services only
Month 4-6: Volunteer migrations from existing services
Month 7-12: Systematic migration of remaining services
Migration Support
- Documentation: Step-by-step guides
- Tooling: Automated migration scripts
- Support: Dedicated help during migration
- Incentives: Recognition for early adopters
Key Takeaways
- Treat the platform as a product; developers are your customers
- Self-service is essential; ticket-based provisioning doesn’t scale
- Provide golden paths (easy defaults) with escape hatches (customization)
- Start with actual pain points from developer interviews
- Build incrementally: CI/CD → Infrastructure → Observability → Portal
- Measure adoption and satisfaction continuously
- Platform team needs infrastructure, engineering, and product skills
- Don’t mandate platform use; make it so good teams choose it
- Meet developers where they are; integrate with existing workflows
A successful platform makes developers faster and happier. Build for them, not at them.