Sepehr Mohseni

Posted on Feb 11

Platform engineering internals: building an Internal Developer Platform (IDP) for your backend teams

#backend #architecture #software #php

Eight months ago, our backend team of 10 engineers was drowning in tickets:

“I need a staging environment.”

“Can someone give me access to production logs?”

“How do I deploy my feature branch?”

Every request meant a Jira ticket, a wait for the platform team, and another context switch for everyone involved.

Today, those same engineers spin up preview environments from pull requests, deploy to staging with a single command, and access logs through a self-service portal. The platform team went from firefighting to building. We reduced environment provisioning time from 2–3 days to ~11 minutes.

This is what building an Internal Developer Platform (IDP) looks like in practice — not the vendor pitch version, but the messy reality of getting there.

Why IDPs Are Becoming More Essential

An Internal Developer Platform (IDP) is a self-service interface that abstracts the complexity of infrastructure, deployment, and environment management, giving developers a unified way to do their work without deep knowledge of low-level details.

It exists to reduce cognitive load and increase engineering velocity.

What a Good IDP Actually Looks Like

A well-designed IDP has five core capabilities that enable developer autonomy while enforcing consistency and governance.

1. Self-Service Environment Provisioning

Developers should be able to spin up feature and test environments without platform team tickets.

# Developer runs: idp env:create --name=feature-payments --from=staging
name: feature-payments
source_env: staging
owner: alice@company.com
ttl: 7d
resources:
  namespace: feature-payments-alice
  database: pg-feature-payments
  redis: redis-feature-payments
  secrets: copied from staging vault

The actual provisioning is handled by infrastructure tooling, but developers interact through a simple CLI or portal.

2. Deployment Pipelines as Code

Every service should deploy the same way using standardized pipelines.

# .idp/deploy.yaml in every repo
service:
  name: payments-api
  team: payments

deploy:
  strategy: canary
  canary:
    - weight: 10
      pause: 5m
    - weight: 50
      pause: 10m
    - weight: 100

  healthcheck:
    path: /health
    interval: 10s
    threshold: 3

  rollback:
    auto: true
    on_error_rate: ">1%"

Developers declare intent. The platform generates the CI/CD, rollout logic, and policies.

3. Secrets and RBAC Without Tickets

Access to production resources should follow role-based rules, not manual approvals.

class SecretAccessService
{
    public function requestAccess(string $userId, string $secretPath, string $reason, int $duration)
    {
        if ($this->isServiceOwner($userId, $secretPath) ||
            $this->belongsToUserTeam($userId, $secretPath)) {
            return $this->grantAccess($userId, $secretPath, $duration);
        }

        return $this->createApprovalWorkflow($userId, $secretPath, $reason, $duration);
    }
}

Most access requests can be auto-approved based on ownership and team metadata.

4. Observability Access

Developers need logs, metrics, and traces scoped to what they own.

teams:
  - name: payments
    members: [alice, bob, carol]
    views:
      dashboards:
        - payments-*
      logs:
        paths:
          - namespace=payments-*

If you own the service, you see its data. No tickets required.

5. Service Catalog With Ownership Metadata

Knowing who owns what and what depends on what is critical as systems scale.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payments-api
spec:
  type: service
  owner: team-payments
  dependencies:
    - component: users-api
    - component: notifications-service

This powers on-call routing, impact analysis, and onboarding.

Build vs. Buy: An Honest Assessment

Build When

You have 500+ engineers
Your infrastructure is custom or legacy
You want full control over developer experience

Buy or Adopt Open Source When

You have 50–200 engineers
You are on standard cloud infrastructure
The 80% solution is sufficient
You need to move quickly

Common building blocks:

Backstage (portal and catalog)
Crossplane or Terraform (infrastructure)
Argo CD / Rollouts (deployments)
OPA (policy guardrails)

A Phased Approach to Building Your IDP

Phase 1: Discover (Weeks 1–4)

Interview developers
Audit ticket queues
Map provisioning and deployment flows

This reveals where the real pain is.

Phase 2: Self-Service Basics (Weeks 5–12)

Automate:

Environment provisioning
Deployment pipelines
Access to secrets and logs

Phase 3: Golden Paths (Weeks 13–20)

Create templates and scaffolding so developers start with best practices by default.

Phase 4: Observability & Cost (Weeks 21–32)

Provide visibility into:

Logs, metrics, traces
Deployment trends
Environment usage
Cost allocation

Common Failures and How to Avoid Them

❌ Building Portals First

UI without automation is useless. Build APIs and CLI first.

❌ Ignoring Adoption

Deprecate old workflows. Track who is still using them and help migrate.

❌ Security Holes in Self-Service

Enforce policies from day one. Self-service must include guardrails.

Measuring Success

Metric	Before	After
Environment provisioning time	2–3 days	~11 minutes
Deployment frequency	~2/week	~8/week
Infrastructure ticket volume	~120/mo	~18/mo
Time to first deploy (new hire)	~5 days	~4 hours

These improvements reflect real gains in developer productivity and system reliability.

Conclusion

An Internal Developer Platform is not a project — it’s an ongoing capability.

Focus on:

Real developer pain points
Automating high-toil workflows
Standardizing environments and deployments
Providing self-service interfaces
Treating the platform as a product for developers

Done right, an IDP turns infrastructure friction into engineering velocity.

DEV Community