Fractional CTO. Full ownership.

A fractional CTO is an experienced Chief Technology Officer who works with your company part-time, typically one to two days a week, instead of as a full-time hire. You get senior technical judgment on architecture, hiring, vendors and risk at the point where those decisions are being made, without carrying an executive salary, equity grant and recruitment cycle before the company is ready for one.

When the decisions are senior but the volume isn't yet full-time. That is usually true when you are pre-Series A, when your founding engineer is strong but has never built at the next scale, when you have just raised and must hire a team and settle an architecture at the same time, or when you need someone to hold the technical line with a board or an investor. Once you have a team of ten-plus engineers and daily executive decisions, hire full-time, and I would rather help you interview for that role than occupy it.

Fractional CTO work is normally priced as a monthly retainer against an agreed number of days per week, month to month, rather than by the hour. I don't publish a rate card, because the honest number depends on scope, domain and how much of the work is hands-on. What I do instead: the first call is free, and it is followed by a fixed-scope, fixed-price assessment so that you know exactly what you are buying before any ongoing commitment exists.

An interim CTO fills a vacant seat full-time for a fixed period, usually after a departure. A technical advisor gives opinions on a light, ad-hoc basis and rarely touches the system. A fractional CTO sits in between and carries real accountability: part-time, ongoing, with decision rights, inside the team rather than beside it. I work fractionally, and I stay hands-on. If I am advising on a system, I have read its code.

Both, and the second is much less useful without the first. I spent thirteen years as CTO while personally implementing the critical path: signaling stacks, routing engines, payment integrations. In an engagement I will read your codebase, review pull requests, and build the components where my doing it is genuinely the fastest route to the outcome. What I do not sell is delivery capacity: if the answer to your problem is "more engineers", you need headcount or an agency, and I will tell you that on the first call.

Yes. Technical due diligence on an acquisition target, a vendor, an outsourced build or your own platform is one of the most common reasons I get called. It runs one to two weeks at a fixed price and ends in a written assessment your board or investors can act on: what is solid, what is technical debt and how urgent, what remediation costs in engineering effort, and which risks are real versus theatrical.

That is the sharpest end of what I do. I have built audit-grade regulatory reporting pipelines for a national tax authority and a central bank, run telecom operator licensing and numbering across markets, and implemented SS7/SIGTRAN and payment protocols from the specifications down to the octet. In regulated domains most generic technical advice does not survive contact with the auditor, and the cost of finding that out late is measured in licences rather than sprints.

They start with a free thirty-minute call, then a fixed-scope assessment of one to two weeks that produces a written plan you own whether or not we continue. Ongoing work is a month-to-month retainer with no lock-in. They end when the problem is solved or the company outgrows the arrangement. Because I document, hand over and train throughout, ending well is part of the design rather than a disruption.

I work remote-first across EMEA on European hours, with an afternoon that overlaps the US East Coast, and I travel on site when the problem justifies the flight. Working languages are English and Greek.