How I actually work with people.
Five shapes of engagement. They all start the same way: tell me about your codebase and the team behind it.
The First Conversation
Anyone looking at their codebase, their vendor, or their release calendar and wondering whether there's a better way to build software.
Thirty minutes on a call. You tell me what you're working with. I ask questions, listen for the shape of it, and tell you what I honestly think. If it's a fit, we talk about how to start. If it's not, I'll point you toward whoever I think is, even if that's someone else.
An honest read on where your codebase stands and whether I can help.
A Digital Twin for Your Engineering Team
Software companies with little to no test coverage, often ones leaning on an offshore or outsourced team for most of their commits, whose leadership wants more velocity without trading away reliability.
Safety net first. I read the code, then build test coverage and guardrails around the parts that matter most. Once the code can tell us when something breaks, I stand up an agentic AI team that learns your codebase and your conventions and starts shipping real code. Every agent has a defined role, and an engineer on your team reviews every merge.
A codebase you can trust again, an agentic AI team shipping into it, and your engineers steering the work rather than typing all of it.
Fractional CTO
Companies that need a senior technical leader in the room, but not a full-time one. Sometimes that's while a digital twin gets built. Sometimes it's while you work out what the long-term technical seat should look like.
I show up regularly. I sit in the technical seat at your leadership meetings. I talk to your vendors, and I tell you plainly what I hear. I help you hire and grow a permanent team when that becomes the right move.
A technical voice in your business you can trust, for as long as you need one.
Technical Due Diligence
Investors, acquirers, and boards who need to know what they're actually buying before the deal closes.
I go through the code, the architecture, the test coverage, the vendor relationships, and the team. I look for the things people know but haven't written down. Then I tell you what I found, in plain language, including the parts nobody in the data room wanted to mention.
A short, honest report on the technology, the risks, and what it would take to fix them.
Architecture Review and Simplification
Teams whose platform has grown heavier every year, where a simple change takes a quarter and nobody can quite explain why.
I sit with the system before I recommend anything. Reading code, talking to the people who run it. Most of my best work has been removing complexity someone else added. At Postmedia, a supposed hard capacity limit turned out to be one configuration change.
A simpler architecture, a clear plan for getting there, and fewer things that can break.
Pricing isn't on a page. Every paid engagement is scoped and quoted once I've seen the code and understand your situation, fixed fee where it can be. You'll know the scope, the cost, and what you'll have at the end before we begin. Fixed price doesn't mean cheap. It just means the cost is decided up front, instead of running on a meter.
Not sure which one fits?
Most people aren't sure when they first reach out. Figuring it out is part of the first conversation.
Start the conversation