Implemented IDP for Faster Onboarding

TL;DR

I built Getir's internal developer platform on Backstage from scratch. 200 engineers use it monthly, and new-hire onboarding got 3x faster—from 60 days to a new engineer's 10th PR down to 20.

Context

Getir was scaling fast as an ultrafast delivery company, with engineering teams spread across multiple countries. Every team was standing up its own infrastructure, naming things its own way, and documenting (or not) wherever felt convenient. New hires were taking 60 days to ship their 10th PR—far too slow for a company adding engineers every week.

Problem

• No visibility into services and their dependencies
• Manual infrastructure requests creating bottlenecks
• Slow onboarding—60 days for new hires to reach their 10th PR
• Each team solving the same infrastructure problems independently
• Documentation scattered across wikis, Slack, and tribal knowledge

The Insight

The pattern was painfully clear: onboarding was slow not because the work was hard, but because nobody knew where anything lived. A new engineer's first real task wasn't writing code—it was a scavenger hunt. Which repo owns this? Who do I ask for staging access? Where's the runbook? The answer was always "ask someone," and that someone was usually in a different timezone.

So the bottleneck wasn't skill or tooling depth—it was discovery. Every new hire was paying a tax to reconstruct knowledge that already existed but was trapped in people's heads and scattered channels. That reframed the whole project for me: I stopped thinking of the IDP as an automation play and started treating it as a single source of truth. Get the map right first, and the speed follows. The catalog—not the templates—became the thing that bent the onboarding curve, because it answered "who owns this?" before anyone had to ask a human.

What I Did

1. Discovery: Interviewed engineering teams across geographies to understand pain points
2. Tool Selection: Evaluated IDP options (Backstage, Port, Cortex) against Getir's requirements
3. Roadmap: Defined phased rollout—service catalog first, then templates, then automation
4. Change Management: Created adoption strategy and training programs

Key Decisions

Backstage as Foundation

I selected Backstage for its extensibility and strong community, and built custom plugins for Getir-specific workflows.

Service Catalog First

Before any automation, teams needed visibility. I started by cataloging all services before adding self-service features—this was the decision that actually moved onboarding, since it killed the "ask someone" scavenger hunt.

Self-Service Templates

I created golden path templates for common service patterns, encoding security best practices by default.

Technical Details

• Backstage Architecture: Kubernetes-deployed Backstage with custom plugins
• Service Catalog: Automated discovery and documentation of 200+ microservices
• Custom Plugins: Deployment status, monitoring dashboards, cost tracking
• Template Library: Golden path templates for APIs, workers, and data pipelines

Results

• Single source of truth for service ownership and dependencies
• New hires productive 3x faster
• Eliminated "who owns this service?" questions

Lessons Learned

1. Start with the catalog: Before automation, teams need visibility. The service catalog was the foundation for everything else—and the part that actually moved the onboarding metric.
2. Golden paths, not golden cages: Templates should accelerate, not constrain. Allow teams to eject when needed.
3. Measure developer productivity: Time-to-10th-PR was a concrete metric that showed real impact.
4. Platform adoption is gradual: Forced adoption fails. I let early adopters prove value, then others followed.