Software Architect & Development Lead
How I work
I don’t sell hours or packages. Here are the problems I’m useful on and the method I use, so you can judge for yourself whether it’s worth writing to me.
01 /
When it makes sense to call me
01
Review of an existing architecture
When a system works but has become hard to evolve. I reconstruct how it is actually built, identify what slows changes down, and hand back a list of interventions ordered by risk-to-benefit, not by technical taste.
02
Legacy application recovery
Applications running for years, with no trustworthy documentation and few people who understand them. I reconstruct real behaviour from the code and the data, and lay out a modernisation path that does not require stopping the service.
03
Technical reference for a team
Working alongside teams growing faster than their own conventions. Defining architectural boundaries, reviewing the decisions that cost too much to get wrong, and handing over the context the group needs to decide on its own.
04
Designing a system from scratch
From framing the problem to module structure and data model. The goal is not the most sophisticated solution, but the one that survives its first two years of change without needing a rewrite.
02 /
How I work
The problem first, technology second
No technical choice before understanding what the system must do and which constraints are real. Decisions made the other way round get paid for over years.
Decisions get written down
An architectural choice without its rationale is one that gets reversed the first time people change. I write down what was decided, why, and what we knowingly chose not to verify.
I leave systems others can maintain
A successful engagement is not one that needs me around to keep working. The measure is how autonomous the team is afterwards.
03 /
Frequently asked questions
- Which technologies do you work with?
- My firmest ground is the server-side Java ecosystem, with relational databases and integrations towards corporate directories. On the client side I have worked extensively with Angular and TypeScript, and published Android applications. That said, what I bring is not the stack: it is the method for deciding which stack makes sense.
- Do you work on systems you did not design?
- That is the most common situation, and the one where I am most useful. Reconstructing an application’s behaviour from its code and data — when documentation either does not exist or describes a system that no longer does — is the skill I am asked for most.
- Do you write code, or only documents?
- I write code. An architecture proposed by someone who never touches the system tends to ignore exactly the constraints that matter. The proportion varies with the engagement, but I never hand over diagrams alone.
- How do we start?
- With an email describing the problem, however messy. From there we work out whether it is the kind of work where I can be useful: if it is not, I will say so straight away.