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 went differently from the whiteboard version, and the differences are where I learned anything worth passing on.

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 folded what existed into a single observability platform on OpenTelemetry instead, 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 value is almost always in connecting what teams already rely on. Handing them one more thing to learn is how the eighth tool gets installed.

At Allianz, standing up a new cloud environment could take more than a year. Each environment needed sign-off from several functions, and no one function owned the end-to-end wait, so a request could sit for weeks with everyone's conscience clear.

We treated provisioning as a product with a roadmap and an owner. Standard environments got self-service templates and Infrastructure-as-Code on a Hub-Spoke architecture, and the compliance checks that used to be a review meeting became pipeline steps. Standard environments came down to days. The first change was organisational: the wait got an owner and a number.

Bundesdruckerei runs identity infrastructure for the German federal government under KRITIS, Germany's critical-infrastructure regime. The reflex, especially among consultants, is to treat that as the thing slowing you down. I found the opposite, on one condition.

Under KRITIS, every architecture decision came with a built-in yes/no test: does this clear the regulatory bar? Restrictive, yes, but it also ends the endless debate. Nobody relitigates a requirement that's written into law. You design against it once and move.

The condition is that you find the binding constraint before you commit to a design. Read the regulation first, write down which requirements cannot be negotiated, and let those shrink the option space. On PLAIN that list was settled before anyone drew a box.

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. 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 the governance was built for that before the platform was. Market readiness reviews with Legal, Security and Compliance ran alongside the build for every launch. How the storefronts were split is on the case study.

Reaching 1M+ users on one platform owed as much to closing that negotiation as to anything we shipped. Each new market reused the onboarding playbook from the one before it.

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.

It came from acting earlier. Detection ran on usage signals, which turned churn from a number in a monthly report into a list of named accounts, early enough to do something about them. An NPS survey would only have confirmed the loss after it happened. Which signals we watched is on the case study.

If your instinct when churn climbs is to ship a feature, check first what the data already knew about the customer, and who was supposed to act on it.

At Telefónica, 21% of cart abandoners completed their purchase within 30 days. The headline is dull (yes, follow up when someone leaves a full cart), and the number came from a decision about restraint.

The marketing-cloud integration had to be quick, dependable and clean under GDPR, which in Germany is the floor. We did not email everyone who bailed. An AI-driven sequence decided when each message went out, and it could hold a message back entirely. What the sequence did across the other channels is on the case study.

At Gesund.de I helped build the platform behind a digital-health marketplace: €417M of Rx revenue flowing through it, prescription flows that stayed compliant as the Gematik specifications shifted, wholesaler and robotics integrations behind the pharmacy counter.

None of that is visible to anyone using the app. They scan a prescription, pick a pharmacy, and the prescription goes through. The regulatory workflow, the pharmacy integrations, the fallback flows for partial fills, all of it sits behind a perfectly unremarkable tap.

That is how I judge platform work now. 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.