Senior Software Engineer & IT Consultant
My clients are banks, insurers, logistics operators and public authorities. And start-ups that first have to prove their idea holds up. For more than twenty years I have worked in the code myself. What I bring beyond that comes from years as an architect and from leadership roles up to CTO and VP Engineering.
The areas below I take on individually or several at once, depending on what you need. In every case I work as part of your team and write the code myself, even when I am also responsible for the architecture or leading a team. That matters to me, because designs otherwise lose touch with the implementation.
Full-stack development centred on Java and Spring, from the data model through the interface into the front end. That ranges from an MVP which first has to prove an idea in the market to applications that carry real transaction volumes and stay in service for years.
From requirements analysis through target architecture to the system landscape. I keep the designs current while the build proceeds, rather than fixing them once at the outset and never touching them again.
Tech lead, team lead, sub-project management. I structure teams and surface dependencies early, so they do not show up shortly before the deadline. I share responsibility for the outcome.
Carving monoliths into microservices, lifting legacy stacks onto current platforms, migrating data. Incrementally, and without the business having to stop while it happens.
Test-driven development, automated suites, CI/CD, code review and release discipline. All of that belongs in the running process. An acceptance test shortly before go-live is too late to add quality.
As a former CTO and VP Engineering I support technology decisions, the build-out of engineering organisations, and the merging of teams and platforms after acquisitions or mergers.
The centre of gravity has always been the Java ecosystem. Around it, everything that running a serious application actually requires has accumulated over the years. I pick up new platforms quickly.
I work mostly in regulated, process-driven environments. The question there is rarely how fast the first version ships. It is whether the result can still be maintained and audited five years later. In younger companies it is the other way round, and I adjust to that.
Consumer credit and distance-selling journeys, SEPA migrations, technical leadership in banking, plus tariff- and contract-driven systems at insurers and building societies.
Investment platforms from prototype through microservice migration into operation at high transaction volume.
Customer portals and self-service applications for providers with consumer bases in the millions.
Process automation and business applications for international freight forwarding and contract logistics.
Back-end development for retail platforms, ordering and fulfilment flows.
Software engineering and quality assurance for the case-processing systems of a German federal authority.
Efficiency and durability of the work come first. Behind that sit a few concrete habits you are welcome to hold me to.
I think highly of clean code principles, and I learned in start-ups how quickly a workable MVP can be up and running. There is no contradiction in that. The skill lies in recognising what matters right now: does the idea have to prove itself in the market first, or are formal correctness and performance the overriding concern? I make that call deliberately, and I say plainly what the shortcut will cost further down the line.
Changes arrive in reviewable units with a history that reads. You can see at any time what I am working on and how far it has come. And what is built today will still make sense to your team without me in the room.
Automated tests are written with the feature, not afterwards. Integration tests run against real databases and real neighbouring systems, not against mocks that always return what you hoped for.
Build, test and deployment run through a pipeline. A release is a button press and a changelog entry, not an evening of manual work.
I write architecture decisions down, together with the alternatives I rejected and the reason for the choice. Otherwise whoever wants to change something later has to guess.
My goal is that your team moves forward after the engagement. Code review, pairing and clean documentation are part of the daily work.
No credentials in the repository, encryption by default, data minimisation as the starting point. In regulated environments this gets audited anyway.
I listen, I translate between the business side and engineering, and I name friction while it is still small. Working relationships from these projects regularly outlast them. I am a little proud of that, and I consider it one of the foundations of good results.
I use locally hosted models and the common cloud services for looking things up, as a source of architectural and implementation ideas, and to get on faster. The code is still written and owned by me. Where policy or confidentiality require it, I work with local models only, or with none at all.
A short description of the task, the timeframe you have in mind and the technical environment is enough to start. You will get an honest assessment back, even when it says I am not the right person for the job.
For confidential messages my PGP key 7B9186D2 is available.
Download the public key