7 Things I Learned Building Enterprise Platforms for Germany's Biggest Companies

Ten years. Seven companies. Hundreds of millions of euros moving through systems I helped build. None of it went according to plan — but all of it taught me something I couldn't have learned from a product book.

Here are the seven things that actually matter when you're building platforms inside large German enterprises.

At E.ON Digital Technology, I inherited six monitoring tools: one for IT, one for OT, one per business unit, two that nobody remembered installing. The obvious move is to build something new. The right move is to consolidate what exists into something everyone will actually use.

We built one unified observability platform on OpenTelemetry — covering IT, OT, and grid — instead of replacing everything. The result wasn't just fewer tools. It was faster incident detection, shared alerting logic, and a team that stopped having meetings about which dashboard to trust.

The instinct to build fresh is strong. Resist it. The value is in the integration, not the invention.

At Allianz, cloud infrastructure provisioning took over a year. Not because the engineers were slow — because every environment required manual approvals, custom networking, and a ticket queue that nobody owned.

We cut it to weeks by treating provisioning as a product: self-service templates, Infrastructure-as-Code in a Hub-Spoke architecture, automated compliance checks baked into the pipeline. The engineers stopped waiting. The platform team stopped being a bottleneck.

If your internal users are waiting more than a few days for an environment, that's not an ops problem. It's a product problem. Fix it like one.

Bundesdruckerei manages identity infrastructure for eleven federal ministries — KRITIS, the strictest classification in German infrastructure law. Most consultants treat this as a reason to move slower. I treated it as a forcing function.

KRITIS compliance meant every architecture decision had a clear success criterion: does this meet the regulatory bar or not? There's no ambiguity. Stakeholders can't argue with the law. And once you've built something that passes KRITIS audit, you've built something that actually works at enterprise grade.

Regulatory constraints narrow the solution space. That makes decisions faster, not slower — if you're willing to make the constraint central to the design instead of bolting compliance on at the end.

Volkswagen Group wanted five brands — VW, Audi, Skoda, Seat, Porsche — on a single commerce backbone. One million-plus users. One platform. Multiple countries, multiple languages, multiple legal entities with their own P&Ls.

The technical problem was tractable. The political problem was harder: each brand believed its customer journey was unique. Each brand's leadership needed to feel like they hadn't surrendered control.

We used a WhiteLabelFrontEnd + MonoRepo approach that gave each brand visual independence while sharing the underlying commerce layer. The architecture served the politics. The 1M+ users on a unified platform wasn't a technical achievement — it was a negotiation achievement made possible by the right technical choices.

Whenever you're building for multiple stakeholders with competing interests, the architecture has to give everyone something to point at as a win.

At Nelly Solutions, we maintained 0.7% monthly MRR churn across 1,200+ medical practices. In healthcare SaaS, that's unusually low. It didn't happen by accident.

The insight: most churn is visible in the data weeks before the practice actually cancels. Usage frequency drops. Support ticket rate increases. Certain features stop being used. We built detection logic around these signals, not just NPS surveys.

If you're trying to solve churn with a new feature, you're probably solving the wrong problem. The question is: what does your data tell you about a practice or customer before they leave? Build the detection first. Build the feature second.

At Telefónica, we had a 21% abandoned-cart recovery rate. That number sounds obvious in retrospect — of course you should follow up on abandoned carts. But the interesting part was how we got there.

The marketing cloud integration needed to be fast, reliable, and privacy-compliant (this is Germany — GDPR is not optional). We built an AI-driven recovery sequence with intelligent send-time optimization, not a bulk email blast. The 21% wasn't from more messages. It was from better-timed, better-targeted ones.

In any product that involves user actions that don't complete, the recovery loop is usually worth more than improvements to the initial funnel. Users who started and stopped are already interested. Go get them back.

At Gesund.de, I helped build a PaaS for digital health — 417M€ in Rx revenue running through the platform, AI/ML personalization for product recommendations, regulatory-compliant prescription flows across multiple markets.

Nobody using Gesund.de knows what the platform does. They click a button, they get a recommendation, the prescription goes through. The complexity — the ML pipeline, the regulatory workflow, the PVS integrations, the multi-market compliance layer — is completely invisible to them.

That's the goal. The better the platform, the less users think about it. If your users are aware of your infrastructure, something has gone wrong.

Ten years in, that's what I keep coming back to: consolidation over invention, provisioning as a product, constraints as forcing functions, politics served by architecture, data before features, recovery loops before optimization, and invisibility as the success metric.

Working on a platform problem that fits one of these patterns? I'd be happy to talk. Book a 30-minute call and tell me what you're building.