Most engineers think in features.
I think in products.
Good software comes from a feel for how the product is used. I write code with the person using it in mind, and after twenty years of building software and two SaaS companies of my own, I know what makes sense in a product.
Why people get in touch
Three situations I see most often. If one of them sounds familiar, write me.
The first version exists, and nobody is sure it will last.
It was built fast, maybe with a lot of help from AI, and it works for the customers you have. Whether it survives the next hundred is a question no one on the team can answer with confidence.
The roadmap is a wish list.
Everything seems important, features ship slower every month, and the decisions that would settle the next year keep getting postponed to the next sprint.
You are about to invest, and the deck says little about the code.
The market story is convincing. What is missing is an independent read on the technology before the money moves.
How I can help
Five ways to work with me, from a one-off review to a seat at the table. Each one starts with a conversation.
For investors before an early-stage deal
Technical due diligence
An independent read on a startup’s technology, written for people who do not read code. Days, not weeks.
For teams with a product in production
Architecture and code review
What holds up, what will break, and what to change first. A prioritised list the team can act on.
For founders deciding what to build next
Product and technology strategy
Working sessions that turn a wish list into a roadmap, with the architecture and the stack to carry it.
For startups without a technical lead
Fractional CTO
Someone accountable for architecture, team and the hard decisions, a few days a month.
When advice is not enough
Hands-on engineering
I build the critical parts myself, or unblock a team for a few weeks, so the plan does not stay a plan.
What makes this different
Everyone says they think along. Here is what that means in practice when you work with me.
I question the concept before anyone builds it.
A feature request is a hypothesis. I ask what it is for, who will use it and what the simplest version looks like, and I push back when the answer is thin. That is product owner work, and it comes with the advice rather than from a separate department.
My advice survives contact with the codebase.
I have built and run SaaS products from the first commit to years of paying customers. Recommendations come with the order to do things in, and when it helps, I prove them in code.
I automate what repeats, in my work and in yours.
Deployments, tests, approvals, reporting. Recurring work gets a pipeline, a script or a workflow, and the hours go back to the product. I bring that habit to every team I work with.
Advice that ends in decisions, not slides.
Every engagement closes with a written set of decisions, in order, with owners and reasons. If you want me to stay and see them through, that is what the fractional CTO role is for.
Work I can show
Products I have built or helped build, from company-defining software to small tools with one job.
TeamGridProject planning and collaboration software for agencies.
VineForecastFarm management and disease forecasting for vineyards.
SignalDBOpen-source database for reactive apps that work offline.
MakeStaticTurns a running website into a static copy that behaves like the original.
CatchFlightsPlane spotting as a game, with the real aircraft overhead.
SimpleSamplerTurns any sound into an instrument you can play.Tell me where your product stands
Three sentences are enough. What you are building, where it hurts, what you plan next. I reply within two working days and tell you straight whether I can help.