Someone has to own the outcome.
I take end-to-end ownership of enterprise applications — building them, running them, changing them, and owning the client relationship around them.
For fifteen years I’ve taken increasingly broad responsibility for enterprise technology in Swiss financial services — from building applications to running them in production, delivering change against them, and owning the client relationship that sustains them. One continuous line of growing ownership.
Four things I own. The rest I coordinate.
Not a list of tools — the places where I’m accountable for the result. Open each for the detail.
Responsibility that runs from the business to the build.
A platform has layers. My role sits across them — translating down, escalating up, and owning what ships.
A short ledger of work that held.
Client systems can’t always be shown in full. I’m glad to walk through the decisions on a call.
Security remediation across the suite
Found the CVE exposure, made the case to the business, and governed dependency and container remediation to closure. My team implemented; I owned the outcome and the customer communication around it.
Multi-application delivery across a single operating cycle
30+ change requests spanning authentication, shareholder data synchronisation, print and proxy workflows, and platform version upgrades — prioritised for client and revenue impact.
Oracle to PostgreSQL, on-prem to Azure
Re-platformed the core application and its database to managed cloud services — a one-to-one functional migration with no interruption to service.
Platform carried through a change of owner
The product moved between owners without a break in delivery or client service. I stayed with it on the other side — the continuity that made the handover invisible to the client.
Built the platform from the ground up
A Java and Oracle application delivered from scratch to replace an incumbent competitor product. Full-stack delivery, hands-on and leading. Still in service today, under its second owner.
How I actually work.
The interesting failures are rarely technical alone.
The ones that cost a client are usually the ordinary ones — a release that’s clean but late, a requirement that’s precise but wrong. I sit between the two sides: business teams get someone who understands what the technology can and can’t do; delivery teams get requirements specific enough to build from, and someone who can tell when an estimate doesn’t add up.
Own the outcome, not just the task.
A requirement that comes back was written wrong the first time.
Read the code. Ask the second question.
Delivery should sustain the relationship, not just the release.
People I build alongside.
Independent professionals I’ve delivered enterprise systems with — and still do.
A long-time delivery partner on Swiss enterprise systems, now building in sovereign AI. Twenty-five years in the field.
Infrastructure and DevSecOps on the platforms I deliver — the layer that stays invisible when it’s done right.
Have something that has to hold together?
Tell me what you’re running and where it hurts. I’ll give you an honest read on whether I’m the right pair of hands.
Based in Olten, working across the Zurich area — on-site or hybrid. English at professional level, German at elementary level. Full CV with client history on request.