Services
Technical consulting
I review architecture, performance and technical decisions when something's stuck or it's time to scale. I find the bottlenecks, tidy up the codebase and leave a clear plan so your team can move forward without dragging technical debt.
How I work
- 01
Context
You tell me what hurts and since when. That's enough for me to decide whether I can help. And if I can't, I'll say so on that same call.
- 02
Read and measure
I read the code, talk to whoever maintains it, and measure: profiling, production metrics, build times. No opinions yet.
- 03
A prioritised plan
A document you can read in twenty minutes: what to fix first, what each item costs, and what you can leave alone.
- 04
Kickoff with the team
For whatever you decide to take on, I stay as long as needed to get it moving with them, not in parallel.
When it makes sense to call me
The recurring reasons: the product is slow and nobody knows why, every release is frightening, the team has grown and decisions contradict each other, or you need to scale and it isn't clear the current architecture holds.
Also the least urgent and most profitable case: a second opinion before a decision that's hard to reverse: changing databases, splitting a monolith, picking a platform. A couple of days of review there saves months.
What a review looks like
First I read the code and talk to whoever maintains it. Then I measure: profiling, production metrics, build and deploy times, coverage where it matters. Only then do I propose anything, because intuitive diagnosis fails far more often than people think.
The deliverable is a short, prioritised plan: what to fix first, what each item costs and what can be left alone. For whatever you decide to take on, I stay as long as needed to get it moving with the team.
What you walk away with
A document you can read in twenty minutes, a conversation with the team, and a list of concrete changes. If the review turns up that your problem isn't technical but one of scope or process, I'll tell you that too.
What's included
Diagnosis from data
Profiling and metrics before opinions. Bottlenecks are almost never where the team thinks they are.
A prioritised plan
A list ordered by impact and cost, not a hundred-page document nobody opens.
Technical debt made explicit
What hurts today, what will hurt in six months, and what you can safely ignore. That last one is a decision too.
Your team keeps the judgement
I work with them, not in parallel. The goal is that they can run the next review without me.
Something got stuck?
Tell me where you are and I'll say whether I can help and where I'd start.
Schedule a call