Jun 15, 2026 8 min read

Building an Internal Developer Platform That Engineers Actually Use

Platform Engineering DevOps

Building an internal developer platform is one of those things that sounds straightforward on paper but turns out to be incredibly nuanced in practice. Over the past two years at PT Bank BTPN, my team and I have designed, built, and iterated on an IDP that now serves 200+ engineers.

The Problem We Started With

Before the platform, deploying a service meant:

  1. Filing a ticket with the infrastructure team
  2. Waiting for manual provisioning (1-3 days)
  3. Configuring CI/CD manually
  4. Setting up monitoring from scratch
  5. Manual secrets management

Engineers spent more time on operational overhead than building features. Something had to change.

Design Principles

We established a few non-negotiable principles early on:

1. Self-Service First

Every capability in the platform must be available through self-service. No tickets. No approvals for standard operations. If an engineer needs a new service, they should be able to provision it in minutes.

2. Golden Paths

We provide opinionated “golden paths” that work for 80% of use cases. For the remaining 20%, teams can customize — but the defaults should get you 90% of the way there.

3. Everything as Code

Infrastructure, configuration, pipelines — everything is version-controlled. This means reproducibility, audit trails, and the ability to roll back.

Architecture

GitLab → Jenkins Pipelines → Docker Build → Nexus Registry → OpenShift Deploy
                    ↑                  ↑
              Vault Secrets    SonarQube Quality Gates

GitLab serves as the single source of truth — code, CI config, and infrastructure definitions all live here. Jenkins orchestrates the actual pipeline execution. Docker builds are pushed to our private Nexus registry. Vault injects secrets at runtime. SonarQube enforces quality gates before deployment to OpenShift.

What We Learned

Adoption is a Product Problem

The biggest surprise? Engineering wasn’t the hard part — adoption was. Engineers don’t adopt tools just because they’re available. They adopt tools that solve their problems better than their current workflow.

We treated the platform like a product:

  • User research with engineering teams
  • Regular feedback sessions
  • Documentation that answered real questions
  • Office hours for onboarding support

Measure Everything

From day one, we instrumented the platform extensively. Key metrics:

  • Time from commit to production (DORA lead time)
  • Platform adoption rate (% of teams onboarded)
  • Self-service success rate (% of requests that don’t need manual intervention)
  • Engineer satisfaction (NPS)

Start Small, Iterate Fast

We shipped a minimal viable platform in 6 weeks. It only supported one service type with a basic pipeline. But it worked, and teams started using it immediately. Each sprint after that, we expanded capabilities based on real feedback.

Results

After 18 months:

  • Deployment time: 70% reduction (from days to minutes)
  • Engineers onboarded: 200+
  • Manual ops tasks: 60% reduction
  • Platform NPS: 72

What’s Next

We’re now exploring AI-assisted operations — using LLMs to help engineers debug deployment failures, suggest pipeline optimizations, and automate incident response. The platform never stops evolving.

This is a continuous journey. If you’re building an IDP, I’d love to exchange notes.