AI Fractional CTO

The title gets used loosely, so here is what the job is in practice. Deciding architecture and being accountable for those decisions later. Hiring engineers and telling you honestly when one is not working. Running delivery so that dates mean something. Talking to investors about the technology in a way that survives diligence. And telling you when to stop building something.

The reason founders rent it rather than hire it is arithmetic. A full-time CTO at a London startup is £130k to £180k plus meaningful equity, and at pre-seed you usually cannot justify either. A fractional one is a few days a month, paid in money rather than ownership, and stops when you have your own.

What it is not is advice. An advisor tells you what they would do and leaves. A fractional CTO makes the call, writes it down, and is still there when it needs adjusting. That distinction is the whole difference, and it is also the honest limit of this tool: it gives you the first half.

Most founders ask too late, usually after an agency has built something they cannot maintain or a first hire has quietly become a bottleneck. There are four signals worth acting on.

You cannot tell whether your developers are doing good work. This is the most common one, and the most expensive to leave alone, because by the time it is obvious you have a codebase nobody else will touch.

You are about to spend real money on something technical and cannot evaluate the options. An agency quote, a platform decision, a rebuild. One person with judgement will save more than they cost in the first conversation.

You are raising and cannot answer technical diligence. Investors ask about architecture, security and team, and "our developer handles that" is an answer that costs you terms.

You are hiring engineers and cannot assess them. Hiring your first engineer badly sets the standard for everyone after them, because that person interviews the next one.

The quality of the answer tracks the detail in the question more closely here than in most tools. "Should we use microservices" gets you a textbook. "We are four people, one backend engineer, a Rails monolith doing 200 requests a second, and our investor keeps asking about microservices" gets you an actual recommendation.

Include the things that feel like they should not matter. Headcount, runway, who is technical, what someone has already been promised. Those are what change the answer, and a model that does not know them gives you the average answer rather than yours.

Read the "what would change my answer" section. It tells you which missing fact would flip the recommendation, which is usually the most useful part of the output and is what you would get out of a first conversation with a real one.

It has not seen your code, your deploy history, your invoices or your team in a room. Those are where the real answer usually is. A contractor who says the codebase needs rewriting might be right, and the only way to know is for someone competent to read it.

It cannot be held accountable. It will not be there in three months when the decision needs adjusting, it does not learn your context between questions, and it has no stake in whether the outcome is good. That is not a small caveat; it is most of what you are buying when you hire a person instead.

It will be confidently wrong sometimes. It is a language model given a paragraph, and it produces the most plausible answer to that paragraph. Use it to structure your thinking and to know what questions to ask, not as the last word on a decision with real money behind it.

Run it and nothing you paste is stored. Submit the form to unlock more runs or to download the answer and what you typed comes to us with your address, which is what the tick box on that form says. Either way, describe the situation rather than pasting code or anything under NDA.