The maths most founders run too late

A full-time startup CTO is one of the largest commitments an early company makes: a senior salary before benefits, and a meaningful slice of the company on top of it. For a business that has raised a seed round, or none at all, that single hire can be the biggest line on the plan and the hardest to reverse. Hire the wrong one and you have spent a year of runway and part of your ownership to find out.

The uncomfortable part is that most companies at that stage do not need a CTO full time. They need a handful of decisions made correctly, early, by someone who has made them before, and then they need the thing built. That is perhaps a day or two a week of genuine technical leadership, and five days a week of a salary.

Fractional closes that gap. You buy the judgement at the density you actually need it, and the money goes into building the product instead of a payroll line. Where cash is the real constraint, the balance between what you pay and what you give up in ownership is negotiable, and settling that split sensibly is usually what makes the numbers work at all.

The number that matters isn’t my rate. It is what a wrong architectural decision costs to unwind eighteen months later, when it is load-bearing and the company is running on it. Nearly every expensive rebuild I have been called into was set in motion by a decision made in the first month by someone who had never had to live with the consequences of one.

What the role actually involves

Deciding the architecture while it is still cheap to change

The stack, the database, the hosting, what is bought and what is built, where the data lives, how users are authenticated. These are all reversible in month one and all painful in year two. Most of the value in this role is spent in the first few weeks, and most of it is in saying no to things that sound impressive and cost you later.

Choosing vendors, and refusing to build what you can buy

Payments, authentication, email delivery, analytics, infrastructure. A good technical lead buys these and spends your engineering budget on the part of the product nobody else can sell you. I have made both mistakes in my own products and I would rather you skipped the expensive one.

Owning delivery, not just advising on it

This is where I differ from most people offering this service. Plenty of fractional CTOs advise, review, and sit in on calls. I still write and ship production code, which means the plan gets tested against reality every week rather than at the end. If a decision I made turns out to be wrong, I am the one it lands on, and you find out from me early rather than from your team late.

Being the technical answer in the room

Investors ask how it scales. Enterprise customers send security questionnaires. A partner wants to know how the integration works. Those conversations go better with someone senior who can answer them directly, and a founder without a technical half often loses deals for no reason other than not having one.

Keeping the infrastructure bill honest

Cloud spend grows quietly and nobody owns it. Running the same review across every product I operate is routine work for me and it usually pays for a meaningful part of the engagement on its own.

Hiring the team, and then handing it over

The goal is to make the role unnecessary. That means writing the specs you hire against, sitting in on technical interviews so you are not evaluating engineers on instinct, setting the standards the codebase is held to, and handing a documented system to whoever comes next. A fractional CTO who makes themselves permanent has failed at the job.

Working as a partnership

The engagements I get the most out of, and I suspect founders do too, are the ones set up as a partnership rather than a purchase order. Someone brings the market, the customers and the commercial instinct. I bring the technical half, and we build something neither side would have built alone.

That has been the shape of most of the portfolio on this site. Several of the products listed there started as somebody else’s idea and somebody else’s industry knowledge, in fields I had no business being an expert in, paired with the part I do know how to do. The founder knew what the software had to be. I knew what it had to be built on. Neither half gets you a product.

In practice that arrangement takes a few forms: a straight retainer where you own everything, a reduced rate paired with an equity stake where we are genuinely sharing the risk, or a defined build with an ongoing technical relationship after it launches. I will tell you plainly which one I think fits, including when the answer is the boring one.

Making the numbers work

Founders often assume this has to be one thing or the other: cash they do not have yet, or handing over a piece of the company they would rather keep. It does not work that way. What you pay and what you offer in ownership are two dials, not one, and where they are set is negotiated rather than fixed. Getting that balance right is often the only reason an early engagement is possible at all.

If you are pre-revenue and protecting every month of runway, weighting the arrangement toward ownership keeps cash in the business where it is doing more good. If you would rather keep the cap table clean and simple, we weight it the other way and you pay for the work. Most arrangements land somewhere between the two, and which one fits depends on your stage, what you are protecting, and how much of me you actually need.

That is a conversation, not a rate card, and I would rather have it properly than publish a number that fits nobody. The one thing I would push back on is ownership instead of payment entirely. That quietly turns your technical lead into an investor whose incentive is the exit rather than the next six months, and what you need is someone solving the problem in front of you.

One thing worth being clear about, because it is the question founders are too polite to ask: you are not hiring one person with a laptop and a ceiling. I bring in experienced developers and specialists when the work calls for it, and I manage them, so the capacity scales without you inheriting a vendor-management problem. What does not change is that you have one person accountable for the whole thing, and you always know who that is.

Who this is right for

A non-technical founder with a real business. You have customers or a clear route to them, and the missing piece is the technical half of the company.
Pre-seed and seed companies that cannot justify a full-time CTO salary yet, but are already making decisions a CTO should be making.
An existing team with no senior technical leadership. Developers doing fine work with nobody setting direction, which is a common and fixable failure.
A company that inherited a codebase from an agency or a departed founder and needs an honest assessment of what they are actually holding.
An established business where software has quietly become the product and is being run as an afterthought.

When you should not hire one

If you have a specific, well-defined thing to build and you already know what it is, you do not need a CTO. You need it built, and that is custom software development, at a lower cost and with less ceremony.

If you are funded well enough to hire a full-time CTO who will also be a co-founder and stay for a decade, hire them. Fractional is the answer to a stage, not a permanent replacement for having technical leadership inside the company.

And if what you actually want is someone to agree with decisions you have already made, we will both be disappointed. The value of this role is entirely in the moments where I say the thing you did not want to hear, early enough that it is still cheap.

How engagements usually run

Most start with a short technical assessment. I look at what you have, what you are planning, what it will cost to run, and where the risk actually sits, and you get a written read on it. That has value whether or not we work together afterwards, and it is a far better basis for a decision than a proposal written before anyone looked.

After that it is normally a monthly retainer sized to how much of me you genuinely need, commonly a day or two a week, with more at the start and less as things settle. Everything is documented as we go, so if you stop, you keep the system and the reasoning behind it rather than a dependency on me. Terms are on the terms of service page.

Where this connects to the rest

The role usually overlaps with the building. Custom software is the product itself, AI integration is the part every board now asks about and most companies get wrong, and MCP development is how a product makes itself usable by AI assistants directly. All of it is on the capabilities page.

A CTO for the stage you’re actually at.