Focus on what you do best.

Mostly companies at an inflection point — a funded startup trying to get from demo to a real product, an enterprise team that's been handed an "AI mandate" with no clear path, or a founder who needs a technical co-pilot before they're ready to hire a full-time CTO. The common thread isn't company size, it's a problem that sits at the intersection of strategy and engineering.

It means I'm in the work, not just reviewing it. That could look like an architecture review of your current pipeline, helping your team build an evaluation harness for your LLM outputs, or designing the middleware layer that makes your AI actually reliable in production. The word "consulting" implies slides and frameworks. What I actually do is closer to embedded senior engineering with a strategic lens.

The "Fractional CTO" label is mostly a billing umbrella. In practice it's the full range of what a good CTO does — and a good CTO isn't a strategic leader floating above the work. They're in the pit when it gets tactical: tech strategy, solution architecture, application engineering, security hardening, hiring, vendor calls, and the decisions that are hard to undo. The fractional part just means you get all of that without the full-time headcount. It makes sense when the foundational decisions are high-stakes — bad ones surface eighteen months later, too late and too expensive to unwind — but you're not ready to bring someone on permanently. The value isn't in the hours. It's in having someone who's been there do the right thing the first time.

Because demos and production are different problems. The model is almost never what's missing. What's usually missing is the business logic layer, an evaluation harness that tells you when the model is wrong, guardrails, observability, and the unglamorous middleware that makes the whole thing stable at 2 a.m. on a Tuesday. That gap between "impressive in a meeting" and "something users rely on" is exactly where I work.

With your actual workflows, not with the technology. Before picking a model, a vendor, or a stack, the more useful question is: where in your business is human judgment a bottleneck versus where is it the value? Half the AI projects I see are process problems wearing AI costumes. I'd rather spend two weeks figuring out whether something should be built than six months building the wrong thing.

Often, yes — and that conversation usually comes early. Processes that need fixing, workflows that need automation, decisions that need clearer ownership: none of these get better by adding a language model on top. I'd rather lose a fee than build something that doesn't help. That's not generosity — it's just how I stay useful to clients over time.

Agencies deliver to a brief. I help you figure out whether the brief is right before anyone writes a line of code. And the engagements that go well are the ones where I leave your team sharper at the end than at the start — not ones where the consultant becomes the bottleneck and knowledge stays with me. If you're looking for someone to take a spec and execute it, an agency is probably faster. If the spec itself is the problem, that's a different conversation.

All the way in, when the work calls for it. I've written production code, designed system architectures, led cloud migrations, and built evaluation pipelines from scratch. What I avoid is reviewing a system without understanding it — that's where expensive advice comes from. I'll read your codebase honestly, sit with your engineers, and tell you what's actually going on under the hood. Where I draw the line is being your developer — that's a bigger waste of your money than my time. If you need execution capacity, hire engineers. If you need someone making sure they're building the right thing the right way, that's the conversation.

It starts with a conversation, not a brief. If there's a clear fit, most engagements kick off with a short diagnostic phase — I need to understand what you've built, what your team looks like, and what "done" actually means before proposing anything. From there it could be a defined project (six to twelve weeks, a clear deliverable), an ongoing advisory arrangement, or a fractional CTO setup. I don't have a fixed menu — the shape follows the problem.

Access and honesty. Access to the people actually doing the work, not just the stakeholders who commissioned it. And an honest picture of where things stand — including the parts that haven't gone well. I've worked inside enough projects to know what a real codebase looks like versus a polished demo, and I'm not here to judge. The engagements that don't go well are usually the ones where the problems stay hidden until they're expensive.

Deliberately few. The sweet spot for me is around three to four engagements at a time — enough to stay sharp across different problems, not so many that any one client gets a diluted version of my attention. I'm honest when I'm at capacity. The kind of work I do requires actually understanding your context — your team, your architecture, your business — and that doesn't scale if you're spread thin.

I work on two models: hourly and retainer. Hourly works well for defined, shorter-duration work — an architecture review, a diagnostic phase, a specific project. Retainers are for when you need me consistently over time, typically a quarter or longer. They give you a guaranteed slice of my attention and usually make more sense when the work is ongoing — fractional CTO arrangements, advisory engagements where the problems are still being defined, or embedded work across a full product build cycle. The right model usually becomes obvious after the first conversation.