Senior technical leadership for teams that need it part-time, from someone who still writes the code.
Roughly one day a week, ongoing. Architecture review, technical direction, and a second pair of experienced eyes on decisions that are expensive to reverse. If you have engineers but nobody senior enough to tell them they're about to build the wrong thing, that's the gap this fills.
What I actually do in the role
- Architecture and design review. On plans before they're built, and on systems already running. The useful version of this is catching the data model that won't survive its second requirement, not producing a document.
- Technical direction for your team. Sequencing work, deciding what gets built and in what order, and being available when someone hits a decision above their pay grade.
- Code review. Regular, on the parts that matter. Teams without a senior engineer tend to accumulate the same handful of problems, and they're much cheaper to catch early.
- Build-vs-buy and vendor decisions. Including the AI ones, where the pitch and the operating reality are furthest apart.
- Hiring support. Technical screening, take-home review, and an honest read on whether a candidate can do the job you're hiring for.
- Hands-on engineering when it helps. I still build. If the fastest way to unblock your team is for me to write the hard part myself, I'll do that rather than write a document about it.
What I'm not
I'd rather set this straight before you email me than after.
I'm not a full CTO, part-time. A real CTO owns technical outcomes over time, sits on the leadership team, carries a headcount budget, and is accountable to a board. That's a job, not an engagement, and doing it properly takes more presence than one day a week. If you need someone in leadership meetings owning the technology function, hire a CTO.
What this actually is: embedded senior engineering, plus the architectural judgment that usually comes with the title. That distinction matters because it changes what you should expect. I'll tell you your architecture is wrong and why. I won't be in your Monday leadership meeting, and I won't own your hiring plan.
I'm not an agency. There's no team behind me. You get one senior engineer, which is the point. It also means I'm not the answer if you need five people shipping in six weeks.
I'm not a prompt-engineering shop. I know how to do it, and I'm good at it but it's not my focus. Most of what I build isn't the model. If your problem is genuinely "make this prompt better," that's a smaller engagement than this one and I'll say so.
When this is the right shape
- You have two to six engineers and no one senior enough to make architecture calls with confidence.
- You're building something with AI in it and want someone who has shipped that specifically, not someone who read about it.
- You've got a system that works but nobody outside its author understands, and that's becoming a risk.
- You need technical direction continuously rather than a single project delivered.
When it isn't
- You need someone in leadership meetings, owning the technology org. That's a CTO, and you should hire one.
- The work is a defined project with a clear endpoint. That's a fixed-scope engagement, and it'll cost you less.
- You need a team. I'm one person.
What it costs
From $3,200 per month, roughly one day a week, four days a month, at base rate. More if the work sits mostly in the AI or advisory tiers; the pricing page has the full rate structure.
Unused days don't roll over. What you're paying for is reserved availability and continuity: someone who already knows your system when the decision comes up, rather than someone who has to be briefed each time.
Arrangements are monthly and either of us can end them. I'd rather you stay because it's working.
How it starts
A call, first, at no charge. Tell me what your team is building and where the gaps are. If a fractional arrangement isn't the right shape, whether what you actually need is a project delivered, a full-time hire, or nothing at all, I'll tell you that.