Services
Work with me.
I take on a small number of engagements alongside my own work, which means I am selective rather than busy. If it is not a good fit, I will say so and try to point you somewhere better.
Consulting
Architecture review
A focused read of what you have: service boundaries, coupling, the dependencies nobody meant to create, and which of the accumulated debt is genuinely costing you rather than merely being untidy. You get a written assessment and a prioritised list of the decisions holding you back - not a slide deck.
Breaking up a monolith
Where the real module boundaries are, and whether you need to cross a network to enforce them. Often a modular monolith is the cheaper right answer and events are not. If you do need them: what to keep centralised, how to introduce asynchrony without turning every bug into a distributed-systems puzzle, and how to sequence the migration so the business keeps shipping while it happens.
Multi-region and scale
Serving users on other continents: read projections, replication lag, failure domains, and an honest accounting of what each option costs you in consistency and in operational load.
Architecture governance for AI-assisted teams
When agents write a large share of the code, review stops scaling. Setting up deterministic checks - structure, impact, regressions - so architectural drift is caught in CI rather than six months later.
How it usually works
Review
A fixed-scope engagement, typically one to three weeks, ending in a written assessment.
Advisory
A recurring slot - a day or two a month - for a team that mostly needs a second opinion at the right moments.
Workshop
A day with your engineers on event-driven design, or on architecture as something you can query rather than argue about.
Talk
Conference, meetup or internal engineering day. Details on the speaking page.
Everything starts the same way: a short call, no charge, where you describe the situation and I ask awkward questions. If there is something worth doing, we scope it after that.
How I work
I have spent twenty-five years on the half of architecture that happens after the diagram is approved, which has left me sceptical of advice that cannot survive contact with a real deployment. So: no reference architectures handed over at the door, no migration plan that assumes a feature freeze, and no recommendation I would not want to be on call for.
In practice that means I want to read the code and the incident history before I have an opinion, I would rather tell you that three of your five problems do not need solving, and I will leave you with something your team can keep running without me.
Tell me what you are dealing with
A few sentences about the system, the team and what is actually hurting is enough to start. I reply to everything.