Something in your system is slow, expensive, or risky. Nobody can say exactly why. I find out what is actually happening, and what to do next.

This is you if

When people call me

Usually one of these sentences has been said in a meeting recently.

• “Releases take three days now. They used to take an hour.”

  The pipeline, the tests, the architecture, the team boundaries: something got slower, and every fix so far made a different part slower.

• “We rolled out AI across the dev team. Shipping is faster. Is anything else better?”

  Reviews got thinner, nobody trusts the tests, the token bill grows, and nobody can say what actually changed.

• “We pay 80k a month for cloud and I couldn’t tell you what half of it does.”

  Hundreds of accounts, services with unclear owners, and no way to say what one product really costs to run.

• “We should migrate this database. Or the cloud. Or the call-center platform.”

  Everybody agrees in principle. Nobody is confident the dependencies are understood well enough to touch it.

• “It fails sometimes.”

  The team has theories. Nobody has a diagnosis anyone would bet on.

• “Due diligence starts in six weeks.”

  Or an audit, or a big customer’s security questionnaire. You want to know what an outsider will find before they find it.

• “We have too many services, too many POCs, too many tools.”

  Maintenance eats the team. You need to consolidate and don’t know what is safe to delete.

Different symptoms, one condition: the system has grown more complex than anyone’s picture of it. From then on every change is a risk and every decision is a guess.

I reconstruct how the system actually works, where the complexity comes from, and what can safely be changed.

The offer

Root Cause Review

One question. One system. Two to four weeks. A decision you can defend.

I review the code, the cloud estate, the pipelines, and the metrics you already have, and I talk to the people who run it. I work out how it actually works, as opposed to how the diagram says it works, where the cost, risk, or friction really comes from, and what that means for the question you asked.

What you get

• A map of the current state, as it really is.
• The actual problem, with the evidence for it.
• The options. Building something is one of them. So is deleting something, consolidating, changing a process, or leaving it alone.
• Effort, cost, risk, and tradeoffs for each option.
• The order: the three things I would do first, and the fifteen I would leave alone.
• A walkthrough with the people who will decide, and the document for the ones who weren’t in the room.

Fixed scope, fixed price, quoted after the intro call. The review is priced on its own, so I have no reason to recommend more technology than you need. Whether you implement with me, with your team, or not at all is a separate decision.

Typical questions

• Should we migrate this?
• Why are releases slow?
• Is our AI adoption actually helping?
• What is all of this costing us?
• What breaks if we change this?
• Are we ready for due diligence?
• Why does this keep failing?
• Can we safely automate this?

Proof

The same pattern, in practice

powerdata GmbH, energy-industry SaaS provider · founder and CIO, 2020–2025

100+ AWS accounts and no map

The situation

“We have a mess of AWS accounts.” More than a hundred, across solutions and teams, with no shared structure, no budgets, no governance, and nobody who could say what ran where.

The diagnosis

The accounts were the symptom. The missing piece was ownership: per solution, per team, with a budget and a review rhythm attached.

The decision and the result

Accounts reorganised per solution and team. Infrastructure as code across all of them. Security Hub governance across the organisation. Budgets with owners, reviewed with 30 engineers. GDPR documentation written and maintained alongside. On that foundation, an omnichannel customer-support automation product for Germany’s largest power and utilities companies that resolved around 50,000 calls a day end to end. In 2024 the company was acquired; platform, product, and paperwork went through full due diligence. Passed.

I wasn’t the consultant on this one. I was the founder and CIO, for five years, living with the consequences of my own decisions. That is the experience I bring into a review.

OpsWorker, AI investigation for Kubernetes alerts · 2025–2026

A year of building with AI, and building AI for operations

The situation

An AI product that turns Kubernetes alerts into root-cause analyses, on top of the monitoring a team already runs. I led the technical side: the agent architecture, the AWS infrastructure underneath, and the engineering decisions around it.

What it taught

Two things. How to put AI on the operations side without it inventing a diagnosis: read-only in the cluster, evidence before conclusions, a human in the loop for judgment. And how to build with AI: a year of agents writing, reviewing, and testing code, and a close look at where that made us faster, where it made the codebase thinner, and what in the process has to change so you can still trust what ships.

Why it matters to you

“Is anything else better?” above is a question I have asked about my own team, with my own token bill in front of me. I spoke about the operations side at WeAreDevelopers World Congress: “Beyond Chat: AI Workflows That Actually Investigate Alerts”.

One of Germany’s largest power and utilities companies

A second cloud, without a second mess

The situation

The company ran on Azure. New products needed AWS, and the question was how to introduce a second cloud into an organisation with existing identity, security, and procurement rules without creating a second, ungoverned estate next to the first.

The diagnosis

The risk was organisational, and it was two years away. A second cloud that starts as “a few accounts for one team” is the next 100-account mess in the making. It had to be built for the organisation it would become, at a scale that was still hypothetical at the time.

The result

Federation with the existing identity provider. An account structure designed for the scale that came later. Governance, budgets with owners, security baselines, and team organisation, all in from day one, so that the teams that came afterwards inherited order instead of a cleanup.

Earlier engagements, and the question each one started with

• mercateo “Can we move this Spring Boot landscape to AWS without stopping the business?” Multi-account CI/CD, infrastructure as code, cost optimisation.
• Siemens “Does this IoT gateway scale, and is a service mesh worth it?” Architecture and code review with scaling proposals; an istio evaluation across AWS and Google Cloud, measured with a custom Go client.
• Gulp “What is actually going on in our estate, security-wise?” A SIEM on AWS, plus an automated code-review toolchain.
• insparx “Can we migrate sensitive data off MySQL safely?” Architecture and implementation of the move to Postgres and MongoDB.
• Data Reply “Can we run Cassandra on AWS without a team babysitting it?” Cluster automation with Terraform.

50,000 calls/day 100+ AWS accounts AWS + Azure due diligence passed