I turn proofs‑of‑concept into teams that ship without me.

You're a fit if:

• You have a working prototype and nobody can say why it isn't a product yet.
• You're a non-technical founder about to make your first senior engineering hire.
• You have 3–20 engineers and no release you'd bet the company on.
• You want an AI capability in the product, not a slide about one.

Not a fit if you want a CTO title on the deck rather than someone in the repo.

How I work: direct feedback, written over spoken, and I expect to be corrected when I'm wrong. Fewer meetings, more merged PRs.

Sound like you? Email me →

I keep complexity in the business domain, not the stack — boring technology a team can actually master. I design for change, not perfection: keep options open, delay the irreversible calls, keep iteration cheap. When assumptions change, the system bends instead of breaking.

The tradeoff: I hold decisions open longer than most are comfortable with. That patience earned the Chief Data Officer Award at Target.

I build execution cultures: real reviews, master always deployable, zero-touch releases. I codified it into The KHIVI Test — ten questions that tell you whether an org is shipping or just busy. I've run it as CTO at two startups.

Small experiments over grand plans. Product, engineering, and business as one team solving one problem.

I push engineers to find their own solutions, walk them through the tradeoffs, and give them real ownership — so the team keeps shipping after I leave.

I wrote Culture Seeds on the patterns that build those teams: hiring, standards, and making quality the path of least resistance.

I run AI-assisted development the way I run any part of the stack: tests non-negotiable, reviews real, nothing ships on vibes.

I'll install the same workflow in your team — skills, guardrails, review gates — so it survives after I leave.

Proof: Cockpit, the open-source tool I wrote for it, and the numbers below.