AI
From Siloed Stacks to a Deployment Rate 3,000 Times Faster
Ten years ago Wehkamp ran dedicated hardware teams for databases, storage, networking, backups, and load balancing. Every change touched multiple teams, each with its own documentation style, its own server naming, and its own change board. The marketing department broke the deadlock. They demanded software out the door within a week, not three times a year. The resulting shadow-IT rebuild shipped multiple times a day. That is a release cadence roughly 3,000 times faster than the previous model, and Wehkamp is still using that foundation today.
What a Platform Actually Means at Wehkamp
A platform is software used to make other software run, from both a runtime and a development angle. Its most measurable job is cutting cognitive load. Expecting every developer to carry full knowledge of every layer is a tax on every small task. Wehkamp’s current platform has a name and a logo, and a developer writing a normal-sized service can write, test, and deploy it without leaving the IDE. Kubernetes handles the runtime. Argo handles delivery. Developers may go their entire career without touching raw YAML or Istio configuration.
Three Backstage Attempts and What They Proved
Backstage looked like the answer. Wehkamp borrowed front-end engineers familiar with TypeScript and Node.js, got the catalog populated, and got excited. Then product owners wanted their people back, the Backstage clone needed constant repackaging, and a tech-docs bug burned hours of debugging time before anyone thought to check the issue tracker. The team tried it again. Then a third time. Each attempt hit the same wall: Backstage is designed for collaboration across large organizations, and Wehkamp’s teams are too small to contribute scaffolder templates on top of their normal backlog.
The Provisioner That Actually Shipped
The working solution is a Slack-based provisioner. A developer clicks buttons, gets a Postgres database or a Kafka queue, and the system opens a pull request signed by a service account. A second bot approves it because repository rules require a reviewer who is not the author. A third bot, Atlantis, applies the Terraform. Cost allocation tags are set automatically, so any dangling resource can be traced to its owner. About 80 to 90 percent of Wehkamp’s services run on this path. Postgres covers almost everything; Kafka covers most of the rest.
Golden Paths Without a Portal
Backstage’s scaffolder concept is still valid even without Backstage running it. Cookie-cutter templates let every new service start with the same defaults and the same lessons already baked in. For observability, a local engineer built a bookmark aggregator: click a link, get your logs or metrics. It is not a full portal, but a stable runtime means developers do not need to live in the observability tools. When something does fall outside string-template territory, engineers open a pull request manually and the same automation pipeline picks it up.
Notable Quotes
the marketing department of all department said the change rate is too low. We want if uh if we have an idea, if you want to do a campaign, that software that the idea needs to be out the door within a week, not three times a year. John Keates · ▶ 08:27
it might be too much platform. That’s essentially the conclusion for the backstage part John Keates · ▶ 20:05
you might solve one bottleneck. Um but there’s also always a new bottleneck over the horizon. John Keates · ▶ 27:35
as it turns out Postgress is great at almost everything. John Keates · ▶ 23:44
Key Takeaways
- A marketing deadline, not an engineering initiative, drove Wehkamp’s 3,000x release-rate improvement.
- Backstage failed three times because the team was too small to maintain a forked TypeScript codebase.
- A Slack provisioner covering 80-90% of services costs far less to maintain than a full IDP.
About the Speaker(s)
John Keates is a Cloud Architect at Wehkamp Retail Group with experience across the full stack, from cloud application architecture to bridging business and technology teams. He contributes to open source and participates in community work, including conference speaking, to avoid narrowing his perspective to a single problem domain.