Most “people problems” are plumbing problems.

The situation

Engineering teams shipping to millions of customers. Every release was a scheduled occasion - work sat in long-lived branches waiting for a window, and when something broke afterwards in an estate that was half cloud and half on-premise, nobody could say quickly which half.

What was actually wrong

Not the engineers. The process rewarded batching up risk until it was too big to reason about, and monitoring told two different stories depending on which side of the infrastructure you asked. Both problems looked like culture. Both were plumbing.

What I built

An enterprise-wide GitLab transformation onto trunk-based development, so small changes went out continuously instead of large ones going out rarely - and a single monitoring layer that covered cloud and on-premise as one picture.

What changed

Releases got 30% faster and incidents were detected 60% sooner. The numbers are the part you can put on a slide. The part that mattered more is that releasing stopped being something anyone had to be brave about.

The situation

A digital bank inside a large regulated group. Everything it built had to be fast enough to compete with fintechs and auditable enough to survive a supervisor asking, two years later, exactly what happened on a particular Tuesday.

What was actually wrong

The usual assumption: that speed and compliance are a dial you trade one for the other on. What that produces is a checklist someone has to remember at the end, which is both slow and, eventually, forgotten.

What I built

Infrastructure where the controls live in the platform rather than in a document - every deployment leaving an audit trail because there was no other way to deploy, not because someone remembered to file one.

What changed

Compliance stopped being a phase at the end of the work. That principle is now in everything Wisqora builds, including for clients who will never meet a regulator: an automation you can’t inspect is one you can’t trust.

The situation

Payment verification infrastructure, running on choices that had been correct when they were made and had simply never been revisited. Everything worked. The invoice went up every quarter and nobody could explain the shape of it.

What was actually wrong

Automation you stop inspecting quietly turns into a subscription. Pipelines were doing work nobody needed, on schedules nobody had chosen, at a size someone had picked two years earlier as a guess.

What I built

A pipeline and infrastructure optimisation that started with reading the bill against what was actually being used - then removing, resizing and rescheduling accordingly.

What changed

20% off the CI/CD cost with no reduction in delivery speed. This is the single most transferable thing I do for smaller businesses: the cloud bill is almost always a document nobody has read closely, and it is almost always wrong in your favour once someone does.

The situation

Mobile banking apps used by millions of people. Eight development teams shared one build and release pipeline that had grown organically for years, the way these things do.

What was actually wrong

Every team was paying for that pipeline - in money and in waiting - and no single team owned it. The cost was invisible precisely because it was spread thinly across eight budgets. Nobody’s line item was big enough to trigger a question.

What I built

A rebuild of the mobile CI/CD from the foundations, designed around what eight teams actually needed rather than what one team had needed first.

What changed

€20,000 a month back on the table, across 8 development teams - same output, less spend, shorter waits. Six years at one institution teaches you something a short engagement cannot: what a system costs to live with, not just what it costs to launch.