Luca BertonYour Internal Developer Platform Is a Product, Not a Project
The #1 reason enterprise IDPs fail: they're built as a one-time project instead of an ongoing product. You wouldn't ship a customer-facing product without user research, iteration, and metrics — your internal platform deserves the same treatment.
This guide walks through building an IDP that developers actually use, from team formation to first golden path to scaling across the organisation.
Phase 1: Team and Strategy (Month 1)
Step 1: Form the Platform Team
Start small but with the right skills:
- Platform lead — Product mindset, can prioritise based on developer needs (not technology coolness)
- Backend engineer — API design, service integration, infrastructure automation
- Infrastructure engineer — Kubernetes, CI/CD, cloud provider expertise
- Developer advocate (part-time) — Gathers feedback, writes docs, champions adoption
Team size: Start with 3-4 people. Scale to 1 platform engineer per 15-25 developers as the platform matures.
Reporting: Platform team should report to engineering leadership, not infrastructure/ops. This signals "developer product" not "IT service."
Step 2: Developer Research
Interview 10-15 developers across different teams:
- "What takes too long?" — Identify the biggest time sinks (environment setup, deployment, debugging production, getting cloud resources)
- "What's confusing?" — Find the knowledge gaps (networking? security? CI/CD configuration?)
- "What would you automate?" — Let developers tell you their pain points
- "How long does it take to deploy a new service?" — This is your baseline metric
Output: Prioritised list of developer pain points ranked by frequency and severity.
Phase 2: First Golden Path (Months 2-3)
Step 3: Build One Golden Path End-to-End
Pick the most common developer workflow and make it effortless:
- Common first choice: "Deploy a web service" — from git repo to production URL
- What it includes: Service template, CI/CD pipeline, Kubernetes deployment, DNS, TLS certificate, monitoring, logging, alerting
- What the developer does: Run one command or click one button. Everything else is automated.
- What the platform does: Creates repo from template, configures CI/CD, provisions infrastructure, deploys, sets up observability
Definition of done: A new developer can go from zero to production deployment in under 30 minutes, following a single tutorial.
Step 4: Technology Selection
Don't over-engineer. Start with what works:
- Service catalogue: Backstage (open-source) or a simple internal wiki until you outgrow it
- Templates: Backstage Software Templates, Cookiecutter, or Yeoman
- CI/CD: GitHub Actions, GitLab CI, or whatever you already use — don't change CI/CD for the platform
- GitOps: ArgoCD or Flux for Kubernetes deployment
- Infrastructure: Terraform/OpenTofu modules with sensible defaults
- Observability: Pre-configured dashboards and alerts (Grafana + Prometheus or Datadog)
Key principle: Use boring technology. The platform's value is in the integration and developer experience, not in novel tools.
Kubernetes Recipes
Practical guide for container orchestration and deployment — hands-on patterns you can use today.
View on Amazon →Phase 3: Self-Service Capabilities (Months 4-6)
Step 5: Expand Self-Service
Based on developer feedback from Phase 1, add capabilities:
- Database provisioning — "I need a PostgreSQL database" → click → database ready with connection string in Vault
- Environment management — Spin up preview environments per pull request, auto-destroy on merge
- Secret management — Self-service secret creation with automatic injection into applications
- Domain/DNS management — Request a subdomain, get TLS certificate automatically
- Access requests — Request access to production logs, databases, or clusters via automated approval workflow
Step 6: Compliance Guardrails (for Regulated Industries)
Bake compliance into the golden paths so developers can't accidentally violate regulations:
- DORA: Automated resilience testing in CI/CD, incident classification webhooks, audit logging by default
- GDPR: Data classification labels on databases, automatic encryption enforcement, retention policy automation
- NIS2: Security scanning in pipelines, vulnerability reporting automation, supply chain verification
- EU AI Act: Model registry integration, bias testing in ML pipelines, human oversight workflow hooks
The principle: Compliance should be the path of least resistance, not an additional burden.
Phase 4: Measure and Scale (Month 6+)
Step 7: Track Platform Metrics
Measure what matters:
- Adoption rate — % of new services using platform golden paths (target: >80%)
- Time to production — How long from "new service" to "serving production traffic" (target: <1 day)
- Developer satisfaction — Quarterly NPS or CSAT survey of platform users
- DORA metrics — Deployment frequency, lead time, change failure rate, MTTR
- Self-service ratio — % of infrastructure requests fulfilled without a ticket to the platform team
- Cognitive load — Number of tools a developer needs to learn to ship a feature
Operationalizing ML Models: MLOps for Scalable AI
Turn ML prototypes into robust, scalable systems using real-world tools. In collaboration with Starweaver.
Start on Coursera →Anti-Patterns to Avoid
- "Build it and they will come" — Without marketing, documentation, and onboarding, developers won't switch to your platform
- Mandating adoption — Forcing teams onto a platform that isn't ready creates resentment. Make it so good they want to use it.
- Platform over-abstraction — Don't abstract so much that developers can't debug production issues. They still need to understand what's running.
- Ignoring existing tools — If teams already use GitHub Actions, don't make them switch to Jenkins because the platform team prefers it
- Technology-first thinking — "We need Backstage" is wrong. "Developers need a service catalogue" might lead to Backstage — or might not.