How I work
Most of what I do starts the same way. A founder who has a development team — or an agency, or a contractor — but no one senior enough to tell them whether the work is going in the right direction. Technical decisions are being made, money is being spent, and there's no clear answer to the question: is this actually working?
The arrangement is usually the same. I come in as the technical counterpart that was missing. Not a consultant with a fixed deliverable, but someone a founder can rely on week to week for an honest read on what's happening and what to do next.
What the work looks like
A regular call — usually weekly — to work through current decisions, blockers, and anything technical that needs a senior voice. What's on the roadmap and whether the order makes sense. Hiring decisions. Whether to rebuild or stabilise. How to evaluate a specific vendor or contractor. The technical conversation you couldn't have with anyone else in the room.
Between calls, I'm reachable for things that genuinely can't wait.
If you have a team, I'll often engage with them directly — running 1:1s, reviewing architecture, shaping how work is structured, giving developers the kind of direction that keeps them moving. The goal is to make the team better at operating, not to make them dependent on me being there.
Who this fits
You're post-revenue — somewhere between early traction and a Series A. You have a dev team, an agency, or some combination of both. The product works, but you can't tell whether the technical decisions being made are good ones.
Something has usually forced the question: a hire you're not sure about, a rewrite recommendation that sounds expensive and vague, a fundraise with due diligence coming, or just the persistent feeling that things are moving slower than they should.
You're not looking for someone to build features. You're looking for someone who will tell you the truth about what's going on.
How it starts
The first few weeks are about getting an honest picture of where things stand — the codebase, the team, the backlog, the decisions already in motion. Not to validate what's been done, but to understand it clearly enough to be useful.
From there, the work shapes itself around what matters most. Sometimes that's hiring, sometimes architecture, sometimes getting a specific delivery over the line. It's rarely just one thing.
How it ends
Most engagements end when a full-time technical hire is made — a CTO, a VP of Engineering, or a senior developer who can carry the direction forward. My job is to make that handover clean: decisions documented, context transferred, nothing important sitting only in my head.
Some end earlier, when the situation that prompted them has been resolved. I don't structure work to run longer than it needs to.
Get in touch
If this sounds like what you need, the best place to start is a conversation.