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 more than 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.
The product was built fast, maybe with a lot of help from AI, and works for the customers you have. Whether the code survives the next hundred is a question no one on the team can answer with confidence.
There is a rough plan, and countless details are still open.
The direction is clear. How the product will look and work in detail is not, and those small decisions will shape it more than the plan.
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. Every engagement 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, and done in days.
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 teams deciding what to build next
Product and technology strategy
Working sessions on where the product goes next and how to build it, with the architecture and the stack to carry it.
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.
For companies without a technical lead
Fractional CTO
Someone accountable for architecture, team and the hard decisions, a few days a month.
What makes this different
Everyone says they think along. Here is what that means in practice when you work with me.
I think about how a product is used while I build it.
For every feature I think about who will use it and how, and I make the small decisions along the way with that in mind. Those decisions shape how the product turns out. Product owner work comes included.
My advice survives contact with the codebase.
I have built and run SaaS products from the first commit to years of daily use. 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.
Work I can show
Products I have built or helped build, from company-defining software to small tools with one job.
VineForecastFarm management and disease forecasting for vineyards.
PatchPilotPatch status for every Linux server you run, in one table.
MakeStaticTurns a running website into a static copy that behaves like the original.
SignalDBOpen-source database for reactive apps that work offline.
BabyfinoA baby monitor app for the evening.
TeamGridProject planning and collaboration software for agencies.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.