Platforms & Infrastructure

AI systems, compliance requirements and internal tools all rest on the same foundation: infrastructure your organisation understands and controls. Platform work is rarely glamorous, but it decides whether everything above it is sovereign, maintainable and affordable.

Why this matters now

Two forces are pulling at the same time. AI workloads demand compute, storage and data pipelines that many organisations never had to run before — GPU scheduling, vector stores, model registries. And the sovereignty conversation is pushing those same workloads out of default hyperscaler regions towards EU providers, on-premise clusters or hybrid setups. Getting both right at once requires deliberate architecture, not another procurement cycle.

At the same time, the tooling that made platform engineering a large-team discipline has become approachable for small teams: declarative infrastructure, containers, managed Kubernetes from European providers, and AI-assisted operations. A Mittelstand company can now own a platform that ten years ago required an enterprise IT budget.

How I approach it

I design for ownership. That means preferring open standards and portable components, documenting decisions as they are made, and building the pipelines and runbooks that let your team operate the platform without me. Every architecture comes with an honest operating-cost model and an exit strategy for each external dependency.

Where legacy systems are involved, I favour integration layers over big-bang replacements: an API in front of the old system, a modern platform beside it, and a migration that moves one capability at a time with a rollback path.

Where it typically starts

Either an infrastructure assessment — what do you run, what does it cost, what would break under an audit or an outage — or a concrete build: a deployment pipeline, an internal platform, a sovereign environment for a specific AI workload.