How to Right-Size Your Internal Developer Platform: Focus on Bottlenecks, Not Breadth

When an organization embraces faster software delivery—shifting testing and operational responsibilities left onto engineering teams—developers gain autonomy but pay a steep cognitive cost. Wehkamp, one of the Netherlands' largest online retailers, learned this lesson the hard way while scaling from weekly to daily releases. The solution wasn't to build a massive, all-encompassing platform; it was to build a focused one.

The Self-Service Bottleneck#

As Wehkamp's release cadence accelerated toward a hundred deployments per day, a new friction point emerged: infrastructure provisioning. Teams that used to hand off deployments to operations staff now managed their own infrastructure—containers, databases, disk allocation, resource scaling. What had been a minor part of quarterly releases became a major blocker in a world of continuous deployments.

Teams started writing their own automation to sidestep delays, duplicating effort and creating inconsistency in tagging, access control, and lifecycle policies. The platform team couldn't keep up. Wehkamp's response was elegantly simple: a chatbot that generated infrastructure pull requests from preconfigured templates, with Atlantis handling Terraform planning and automated application. Resources went from request to deployment in roughly a minute.

This single tool didn't just accelerate provisioning—it also enforced standards and reduced cognitive load by cutting down the variety of ways teams could set up resources.

Defining What a Platform Actually Is#

As the company pushed toward 100 releases per day, Wehkamp realized it needed a more intentional platform strategy. The challenge: platform engineering can mean vastly different things. Should a platform be a low-level foundation of primitives? A high-level scaffolding system? A catalog where teams contribute their own building blocks?

The team mapped two spectrums. The first balanced technical abstraction (Do we provide primitives or solutions?) and community involvement (Is the platform top-down or collaborative?). The second introduced governance models:

• Consume-only resources: services teams use but never configure—cloud infrastructure, observability systems
• Multiparty resources: concerns like messaging and traffic that require shared standards across teams

Plotting capabilities on this grid revealed where the platform should focus effort. A foundational service in the top-left corner (consume-only, fully provided) is a platform win. Internal SDKs or Kafka topics—where teams both produce and consume—fit elsewhere.