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

Ten years, seven of Germany's largest companies, hundreds of millions of euros moving through systems I helped build. Most of it didn't go the way I drew it up on the whiteboard, and that gap is where the lessons live.

When I joined E.ON Digital Technology, the monitoring estate had grown to six tools: one for IT, one for OT, one per business unit, and two nobody could remember installing. The symptom showed up every time something broke. We'd get on an outage call and spend the first ten minutes arguing about which dashboard to believe.

Everyone wanted to build the seventh tool that would finally replace the other six. We didn't. We folded what existed into a single observability platform on OpenTelemetry, across IT, OT, and grid. Fewer tools was the visible result. The one that mattered was that the arguing stopped: shared alerting, one source of truth, faster detection.

I've watched the build-it-fresh instinct play out enough times to distrust it. The leverage is almost always in connecting what teams already rely on, not in handing them one more thing to learn.

At Allianz, standing up a new cloud environment could take more than a year. The engineers weren't slow. Every environment needed manual approvals, hand-rolled networking, and a trip through a ticket queue that no single team owned, so requests just aged in place.

We got it down to weeks by treating provisioning as a product in its own right: self-service templates, Infrastructure-as-Code on a Hub-Spoke architecture, compliance checks built into the pipeline instead of bolted on at review. Engineers stopped queuing for environments and started using them.

When internal users wait days for something the platform should hand them in minutes, the bottleneck usually isn't ops capacity. It's that nobody has decided their wait is a problem worth designing away.

Bundesdruckerei runs identity infrastructure for eleven federal ministries under KRITIS, the strictest tier in German infrastructure law. The reflex, especially among consultants, is to treat that as the thing slowing you down. I found it did the opposite.

Under KRITIS, every architecture decision came with a built-in yes/no test: does this clear the regulatory bar? Restrictive, yes, but it also kills the endless debate. Nobody relitigates a requirement that's written into law. You design against it once and move. And a system that survives a KRITIS audit is, almost by definition, one that holds up under real enterprise load.

A hard constraint shrinks the space of things you're allowed to build, which is exactly why the calls get faster, as long as you let it shape the design from the first sketch instead of meeting it at the audit.

Volkswagen Group wanted five brands (VW, Audi, Skoda, Seat, Porsche) on one commerce backbone: a million-plus users, several countries and languages, separate legal entities each running its own P&L.

The engineering was the manageable half. The hard half was political. Every brand was convinced its customer journey was special, and every brand's leadership needed to come out of the project feeling they hadn't handed over control of it.

So we built for that. A WhiteLabelFrontEnd on a MonoRepo let each brand keep a visibly distinct storefront while sharing the commerce layer underneath. The architecture was shaped by the negotiation, not the other way around, and reaching 1M+ users on one platform owed as much to closing that negotiation as to anything we shipped.

When you build for stakeholders who are quietly competing, each of them has to find something in the design they can point at and call theirs.

At Nelly Solutions we held monthly MRR churn at 0.7% across more than 1,200 medical practices. For healthcare SaaS that's low enough that people assumed we were measuring it wrong.

What it actually came from was looking earlier. A practice that's about to cancel usually tells you weeks ahead, in the data: logins thinning out, support tickets piling up, whole features going quiet. We wired detection to those signals and flagged accounts while there was still time to act, rather than waiting for an NPS survey to confirm what we'd already lost.

If your instinct when churn climbs is to ship a feature, you're usually treating a symptom. The leverage is in what your data already knows about a customer before they decide to leave.

At Telefónica we got abandoned-cart recovery to 21%. In hindsight the headline is dull (yes, follow up when someone leaves a full cart), but the number didn't come from doing the obvious thing louder.

The marketing-cloud integration had to be quick, dependable, and clean under GDPR, which in Germany is the floor, not a nice-to-have. Instead of blasting everyone who bailed, we built an AI-driven sequence that optimized when each message went out. The 21% was a timing and targeting result; sending more email would have dragged it down.

Someone who started checking out and stopped has already told you they're interested. Earning that second look is usually worth more than another round of tuning the top of the funnel.

At Gesund.de I helped build the PaaS behind a digital-health marketplace: €417M of Rx revenue flowing through it, ML personalization on the recommendations, prescription flows that stayed compliant across several markets.

None of that is visible to anyone using the site. They tap a button, get a recommendation, the prescription goes through. The ML pipeline, the regulatory workflow, the PVS integrations, the per-market compliance layer, all of it sits behind a perfectly unremarkable click.

That's the whole point. The better the platform, the less reason anyone using it has to think about it. The day your users start describing your infrastructure back to you is the day something underneath has begun to leak.

---

If one of these patterns looks like the thing you're wrestling with right now, I'm happy to compare notes. Book a 30-minute call and tell me what you're building.