Why I stopped doing fractional CTO work

For ten years, the fractional CTO model worked for me. I'd sit down with a founder, look at their codebase, listen to their team, and within a week I could tell them what was breaking and what to do about it. The pattern was always the same. Same engineering anti-patterns, same communication gaps, same architectural shortcuts that worked at five engineers and broke at fifteen. I got good at diagnosing it.

What I didn't notice for the first eight years is that I was diagnosing the same thing every time.

The same problem, over and over

It wasn't that the founders were bad. It wasn't that the engineers were bad. The teams I worked with were full of smart, careful people doing their best with the tools they had. The pattern that broke was always upstream of the code. It was the gap between what the founder meant and what the team built. Sometimes that gap was a Slack thread that meandered for three days. Sometimes it was a Notion doc that got rewritten four times. Sometimes it was a regulatory constraint nobody flagged until the build was halfway finished. Different surface, same underlying problem.

I wrote the same six clarifying questions to thirty different founders. I sat through hundreds of planning sessions where the room slowly figured out what was actually being built. I watched specs get written in PMs' heads, lost in handoffs, reconstructed by engineers who guessed at the original intent. After enough of these, the engagements started to feel like rehearsals of the same play.

You see this kind of pattern once, you assume it's bad luck. You see it across thirteen years of agency clients and fractional engagements, you stop calling it a pattern. You start calling it the shape of the work.

Why patching stopped being enough

The shape of the work was a problem I could see clearly and couldn't fix from inside a client engagement. I could help one team at a time. I could write better specs for them. I could tell them how to communicate better. None of it was infrastructure. The next team I worked with had the same problem all over again, because I was patching, not fixing. The fix had to live somewhere outside any single team. In a tool, in a substrate, in something that would still be there after I left.

I had the idea for Kommit in some form for years. The math didn't work. A tool that helps you write better specs wasn't something anyone in 2018 wanted to pay for, because the specs went into a human engineer's head, and the cost of bad specs was diffuse. Absorbed into overtime, rework, and founder self-blame. There was no acute pain to monetize.

Why it changed now

Then 2025 happened. Claude Code shipped. Cursor agents got real. Devin and Codex and Replit Agent turned the abstract phrase "AI writes code" into something engineers used on a Tuesday afternoon. And the diffuse cost of bad specs collapsed into a single, sharp pain that every team using these tools felt within their first month. The agent is brilliant, and somehow the output is still wrong.

The bottleneck moved upstream. The market arrived. The product I'd been sketching for thirteen years suddenly had a reason to exist.

Why I stopped

I closed the fractional CTO chapter on March 8, 2026. I had already been working on Kommit before that, conceptualizing it, thinking through the architecture, and running small experiments since December 2025. I haven't taken a new client engagement since.

This was harder than I expected. Fractional CTO work paid well. The relationships were good. Some of those founders are still texting me with technical questions, which I'm happy to answer because I genuinely care about what they're building. But I'm not coming back. The thing I want to fix can't be fixed one engagement at a time. It has to be infrastructure.

I spent thirteen years watching the same problem break. I'm done diagnosing it.