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
Call and 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 your team, 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 I review
Two fronts, and they almost always touch. Architecture and scalability: where the current design runs out of room, what's coupled to what, whether the data model holds the volume that's coming, and whether splitting the monolith or changing databases solves anything or just moves the problem somewhere else.
Performance, front and back: backend profiling, slow queries, build and deploy times, and Core Web Vitals in the browser, which is where the slowness shows up even when it starts three layers further down.
From one-off review to fractional CTO
Some projects don't get their hard decisions one at a time. When the volume is high and sustained, a one-off review falls short: what you need is technical judgement on the inside and on a continuous basis, without opening a full-time CTO position.
That's where the engagement turns into a fractional CTO: the same work as a review, architecture, priorities and decisions that are hard to reverse, but recurring and with part of the responsibility on the inside. It isn't where anyone starts. You get there after a first review, once we both know whether it makes sense.
What I don't do
I don't hand over a hundred-page audit. Nobody opens them, and three months later they no longer describe the system. I don't stay to execute the whole plan either: I get whatever you decide to take on moving with your team, and they carry it from there.
And not every review ends in work. If it turns out the current architecture holds what's coming, that's a result too, and probably the cheapest one you'll get.
What's included
The bottleneck isn't where you think
It's almost never where the team points. Diagnosing by eye ends up optimising the thing that wasn't the problem.
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 and explain the why, not just the what. The goal is that they can run the next review without me.
An exit when the problem isn't technical
Sometimes what's slowing you down isn't the code but the scope or the process. I'll tell you that too, even if the engagement ends there.
Something got stuck?
Tell me what's going on and I'll say whether I can help and where I'd start.
Schedule a call