Fractional CTO red flags: how to spot a bad one

The fractional CTO red flags that separate builders from advisors

Fractional CTO red flags are harder to spot than they should be, because the words used by advisors and builders are almost identical until the contract is signed. Both say "embedded", "strategic", and "systems". Both sound senior in the first call. Only one of them will have a working system running inside your stack three weeks later, and the other will hand you a slide deck and an invoice. You usually cannot tell which is which from the pitch, so you have to test for it directly.

This guide gives you six specific warning signs to check before you sign anything. Each one is something you can ask about or watch for in the first two meetings, before money changes hands. If you want the broader picture of the role first, read what is a fractional CTO for the full definition. This piece is narrower: it is about how to spot a bad one.

Red flag 1: the first deliverable is a document

The most common warning sign in the fractional CTO market is a first month that produces paper. The engagement starts, and the first deliverable is a 40-page technical audit with findings, recommendations, and a prioritized roadmap. It looks thorough. It feels like progress. It is, in practice, a consultant billing you for a report.

A real fractional CTO produces an audit too. The difference is that the audit is the input to the build, not the output of the engagement. If the first three months produce documents and no code, you are paying for someone who does not build. Ask what will be running in production by the end of month one. If the honest answer is "a finalised roadmap", you have found your first red flag and you have found it cheaply.

Red flag 2: they cannot explain what code they will write

A fractional CTO who builds can tell you, in specific terms, what system they will deliver in the first quarter. "A WhatsApp qualifier that takes a cold inquiry, asks five qualification questions, and routes the qualified leads to your Calendly booking link" is a specific answer. "We will implement an AI-driven customer engagement workflow" is a red flag answer dressed up to sound like one.

Ask the question directly and refuse to accept a vague reply: what specifically will be running in our production environment in 30 days? A builder names a system, a trigger, and an outcome. An advisor names a category and a buzzword. The gap between those two answers is the gap between someone who writes code and someone who writes recommendations about code other people might write later.

Red flag 3: they are selling you a product they own

Some fractional CTOs arrive with a proprietary platform, a SaaS tool they resell, or an agency network they take a cut from. The engagement quietly becomes a reason to deploy their product into your stack. Every architecture recommendation points at the same vendor. Every build-versus-buy decision somehow resolves to "buy", and the thing to buy is theirs.

A genuine fractional CTO makes the call that is correct for your stack, your cost structure, and the maintenance capacity of your team. They have no financial interest in a specific vendor, so they are free to tell you when the right answer is a 200-line script instead of a platform subscription. Ask it plainly: do you have any commercial relationship with the tools you are recommending? An honest one tells you. A conflicted one gets vague.

Red flag 4: no named clients and no specific outcomes

"I have worked with businesses across fintech, hospitality, and healthcare" is a non-answer. It is a list of industries, not a list of results. Compare it to a real one: "I built a WhatsApp qualifier for a clinic that cut their response time on inbound inquiries from hours to minutes, and their booking rate moved within the first 60 days." That second answer can be checked. The first cannot.

If a fractional CTO cannot name a specific outcome from a specific client, anonymised is fine but specific, then one of two things is true. Either they are new, or they do not track the results of their own work. Both are problems. A builder who has delivered real systems remembers exactly what moved, because the metric moving is the entire point of the job. Vagueness about outcomes is vagueness about whether the work ever produced any.

Red flag 5: a six-month minimum before any system is built

A fractional CTO who is genuinely embedded in your team and building should be able to show a working output in month one. A six-month minimum commitment before you see a single line of deployed code is a contract structure that protects the consultant, not the client. It guarantees revenue regardless of whether anything ships.

Legitimate engagements are usually structured around monthly commitments with 30 days notice, because the work is continuous and the outcomes are visible quickly. There is no reason to lock a client in for half a year before delivering anything, unless you are worried the client will leave once they see how little is being produced. If a fractional CTO needs six months to make something you can evaluate, ask what exactly you are paying for in months one through five.

Red flag 6: they talk about technology trends instead of your problem

A fractional CTO who opens the first meeting with GenAI, large language models, and the future of autonomous agents, all before understanding your actual stack and your actual problem, is positioning as a thought leader, not a builder. The trend talk is impressive in the room and useless in production. It tells you what is in the news, not what should run in your business.

Your real problem is more boring and more valuable than any trend. It is that three SaaS tools do not talk to each other and your team spends four hours a day on data entry that should take fifteen minutes. That is the conversation a genuine fractional CTO starts with, because that is where the money is. The technology trend discussion belongs in the article they publish after the engagement, not the sales meeting before it.

What a legitimate engagement looks like instead

The shape of a good fractional CTO engagement is simple and fast. Week one is the audit: map the stack, the costs, and the highest-pain workflows, then produce a prioritized build list. Week two, building starts on the first system. Week three, that system is live and the client is using it on Monday morning. Then you move to the next item on the list. The roadmap is the queue of things being built, not the product being sold.

Most engagements that go wrong do so because the upstream data was broken before the AI layer had anything useful to work with. A good fractional CTO finds that in week one and fixes the plumbing before promising any clever automation on top. The order matters: clean data first, then the system that reads it, then the metric you are trying to move. Anyone selling the clever layer before checking the plumbing is selling you the part that demos well, not the part that works.

How twohundred approaches this in practice

When we take on a fractional CTO engagement at twohundred, the first system goes live in weeks two to three, not month six. The audit happens in week one, building starts in week two, and the client is using something real before the first invoice feels expensive. We do not resell anyone else's platform, so the build-versus-buy call is made on your costs, not our margins. If a problem is solved better by a small script than a subscription, you get the script. The practical test we would give any operator evaluating us, or anyone else, is on the fractional CTO services page: ask what runs in production in 30 days, ask for one named outcome, and ask about vendor relationships. If the answers are specific, you are probably talking to a builder.

Frequently asked questions

How do I evaluate a fractional CTO before signing?

Ask three questions and listen for specifics. What exactly will be running in our production environment in 30 days? Can you name a concrete outcome from a previous client, anonymised is fine? Do you have any commercial relationship with the tools you recommend? A builder answers all three with detail. An advisor answers in categories and buzzwords. The texture of the answers tells you more than any case study.

What should a fractional CTO contract look like?

A monthly commitment with 30 days notice is the standard shape for a legitimate engagement. The work is continuous and the outputs are visible quickly, so there is no need to lock a client in. If the contract demands six months upfront or a multi-year minimum before any system is built, that structure protects the consultant rather than the client. A genuine fractional CTO is confident enough in their output to work month to month.

What is the difference between a fractional CTO and a technology advisor?

A fractional CTO builds and ships code. A technology advisor gives recommendations and pressure-tests your direction. Both are useful, in different situations. If you need someone to make the technology decisions and build the systems that execute them, hire a fractional CTO. If you already have a builder and you need a second opinion on strategy, hire an advisor. The red flags in this guide mostly catch advisors who are charging fractional CTO rates while calling themselves builders.

How much should a fractional CTO cost compared to a full-time hire?

A full-time CTO earning £150,000 to £220,000 a year makes sense when the business needs architecture decisions every day and a technology voice in senior leadership. A fractional CTO at £2,000 to £5,000 a month fits most SMEs in the £1m to £10m revenue range, who need senior judgement two or three days a month, not twenty. The fractional model also lets you change direction without an expensive hire-and-fire cycle. The cost only makes sense if real systems ship, which is exactly what the red flags above are checking for.

---

Related Services

For businesses working through an AI strategy before committing to a build, AI consulting services covers the advisory and planning layer. When ready to move from strategy to deployment, AI implementation services covers the full rollout.