The biggest fractional CTO red flags are vague deliverables, a pet tech stack, no references, too many clients, accounts held in their own name, undisclosed vendor commissions, overpromised timelines and equity-first demands. None of them is subtle once you know what to look for, and each has a fix: a question, a contract clause or a polite goodbye.
I'm a fractional CTO myself, so read this as the list I would want a founder to hold me to. The twelve flags are grouped by where they tend to appear: in the sales conversation, in how the person would run your technology, and in who ends up with control and money.
Red flags in the sales conversation
People are on their best behavior while they are selling. Whatever you see now is the ceiling, not the floor.
1. Slow or sloppy communication during the sale
Replies take days. The proposal arrives late with your company name misspelled. A call starts fifteen minutes late with no message. None of this is a crime, but it is a preview: when you are one of several clients and something breaks on a Saturday, it will not get better.
What to do instead: treat the sale as a work sample. Note how long replies take, and ask for a one-page written summary after your first call. It is the closest thing you will get to a preview of their weekly updates.
2. Vague deliverables
The proposal promises “strategic technical leadership” and “architecture guidance,” and nothing you could check in three months. Vague scope protects the seller, because nobody can say whether it is working.
What to do instead: ask them to turn your goals into three to five deliverables for the first 90 days, such as a costed roadmap, a first release in the app stores or two engineers hired. Put those in the statement of work. If they resist being pinned down at all, that is your answer.
3. Overpromised timelines
Before seeing any code or spec, they promise your marketplace, two mobile apps and an admin panel in six weeks, or they simply match whatever deadline you mention. An estimate given before discovery is either a guess or a sales tactic, and both end in cut corners or a missed date.
What to do instead: ask how they would estimate. A good answer explains what they need to see first, gives a range rather than a date, lists assumptions and says what is out of scope. Be more wary of the person who says yes to everything than of the one who says “it depends.”
4. No references
“My clients are all confidential,” and no way to speak to anyone. Keeping client names off a website is normal; plenty of us work under NDA. Refusing to connect you privately with a single past client is not.
What to do instead: ask for two founders you can call, including one whose engagement has ended. If the person is newly independent, former managers or colleagues are a fair substitute, combined with a short paid trial.
Red flags in how they would run your technology
These show up once the conversation turns to your product. They are about judgment and focus rather than manners.
5. They push a pet stack
Every client gets the same framework, the same cloud and the same database, chosen before anyone has looked at your product. Or the reverse: a fashionable, exotic stack that few developers in your market know. Your stack decides who you can hire and what change will cost, long after the CTO has moved on.
What to do instead: ask for the reasoning in terms of your product, your hiring market and your budget, and ask what they would choose if they knew they were leaving in a year. Sensible defaults are fine (good CTOs have them); being unable to explain them is not. For a yardstick, read how to choose a tech stack that outlives any one CTO.
6. They won't touch code when you need someone hands-on
You have no developers, and the plan is “I'll write the strategy, then you hire a team.” Or they haven't written production code in years but say they will build your MVP. Advisory work is valuable when a team exists. Without one, you are paying for directions with nobody to drive.
What to do instead: decide which kind of fractional CTO you need before you shortlist, then ask builders to show you something they personally shipped recently. I'm the hands-on kind, so I'm biased, but the reverse also applies: if you already have a strong team, an advisory CTO may be the better pick.
7. They have too many clients
They list a long roster of current clients, or can't say how many. Meetings only fit into odd slots. Fractional means shared, but there is a ceiling. In my experience, a hands-on CTO can only carry a few active builds at a time; an advisory CTO can handle more because the hours per client are lighter.
What to do instead: ask directly how many clients they have and how many hours each gets, then put your hours, overlap times and response times in the contract.
8. No security basics
They share passwords over chat, suggest one admin login for everyone or never mention backups. Early-stage security does not need to be elaborate, but the basics are cheap and the failures are expensive.
What to do instead: ask what they set up in the first month. A concrete answer includes individual accounts with two-factor authentication, a company-owned password manager, access limited to what each person needs, automated backups that have been test-restored, and monitoring that alerts someone when things break.
Red flags about control, money and incentives
These are the quiet ones. They rarely show up in a pitch, and they do the most damage when the relationship ends.
9. Accounts in their own name
They offer to register your domain, cloud account, code repository or app store account under their own name or company, “to save time.” Whoever holds the accounts holds your product. Even with good intentions, you depend on them for access, and if things end badly you could lose your app or your domain.
What to do instead: every account sits in the company's name, paid for by the company, with the founder as owner and the CTO as a named admin. Put it in the contract. The guide to keeping code and accounts in your company's name covers what to check.
10. No documentation, so you stay dependent
Months in, nothing is written down: no architecture overview, no record of why decisions were made, no steps for deploying, no list of services and who pays for them. All the knowledge lives in one head, which makes that head very hard to replace.
What to do instead: make documentation a deliverable, not a favor. Ask for an architecture overview, a decision log, a deployment runbook and an inventory of accounts and vendors, and review them once a month. A good CTO writes things down because they plan to be replaceable.
11. Undisclosed vendor kickbacks
They push hard for one agency, offshore team or tool, and never mention that they receive a referral fee or own part of it. The vendor may be perfectly good. The problem is that you can no longer tell whether the advice serves you or them.
What to do instead: ask in writing whether they receive any payment, commission or equity from vendors they recommend, and add a disclosure clause to the contract. For any big vendor decision, ask for two or three options with the trade-offs laid out, so the choice stays yours.
12. Equity-first demands
Before doing any work, they ask for a sizable stake, or offer to work for equity alone with loosely defined hours. Equity is permanent; the commitment may not be. Equity-only deals also make it hard to hold anyone to deliverables or to end things cleanly.
What to do instead: start with a paid engagement. If equity makes sense later, keep it small and vest it over time. Here is how to structure equity for a fractional CTO without regretting it.
Which fractional CTO red flags are dealbreakers?
Not every flag means walk away. Some are fixed with a clear contract; others tell you something about the person that no clause will change.
| Red flag | Verdict | What decides it |
|---|---|---|
| Slow, sloppy sale | Usually walk away | It rarely improves after signing |
| Vague deliverables | Fixable | Whether they agree to written 90-day goals |
| Overpromised timelines | Fixable | Whether they revise after discovery |
| No references | Usually walk away | Unless a paid trial proves the work |
| Pet stack | Fixable | Whether they can justify it for you |
| Won't code | Walk away if you need a builder | Fit, not quality |
| Too many clients | Depends | Hours and response times in writing |
| No security basics | Fixable early | A baseline agreed on in month one |
| Accounts in their name | Walk away if they won't move them | Who controls your product |
| No documentation | Fixable | Docs as a monthly deliverable |
| Hidden vendor kickbacks | Walk away | Trust, not the fee itself |
| Equity-first demands | Usually walk away | Whether they accept cash first |
Rule of thumb: one flag is a conversation. Two flags from the same group is a pattern. A refusal to fix any flag is your answer.
How to check for these before you sign
You can test for most of these in a normal hiring process without making it awkward:
- Ask for a short written summary after the first call (flags 1 and 2).
- Run a short paid discovery before any retainer (flags 3, 5, 6 and 8).
- Call references, including one engagement that has ended (flags 4 and 10).
- Ask about client load and vendor income in writing (flags 7 and 11).
- Put account ownership, documentation, disclosure and hours in the contract (flags 7, 9, 10 and 11).
- Leave any equity conversation until you have worked together for a few months (flag 12).
For the call itself, use these twenty questions that bring most of these flags to the surface. For the order of steps, from brief to signed contract, follow a hiring process built around a paid discovery.
The bottom line
Most red flags are not about technical skill. They are about honesty, focus and who holds the keys. A good fractional CTO is specific about deliverables, open about other clients and vendor relationships, happy to keep everything in your company's name and keen to write things down. If someone resists any of that before you have signed, it will not get easier after.
Frequently asked questions
Is it a red flag if a fractional CTO works with several companies?
No. Working with several companies is what makes the model affordable. The red flag is overload that nobody admits to. Ask how many active clients they have, how many hours each one gets and how they handle two urgent problems at once. Advisory CTOs can carry more clients than hands-on ones, because building a product takes far more hours than reviewing one.
Is it normal for a fractional CTO to keep client names confidential?
Yes. Many engagements are under NDA, so case studies often describe the work without naming the client. That is different from refusing references. A fractional CTO with a track record should be able to ask a past client to take a private call with you, or show you work with permission. If nobody at all will vouch for them, treat that as a warning sign.
What should I do if my current fractional CTO shows these red flags?
Secure control first: move any accounts in their name to the company and make sure you have owner access to the code, cloud, domain and app stores. Then raise the issue directly against agreed deliverables, ask for documentation and set a clear deadline. If nothing changes, give notice under the contract and arrange an independent review of the code before the handover finishes.
Is it a conflict of interest if a fractional CTO also builds the product?
Not in itself. A CTO who builds removes the gap between the person deciding and the person doing, which is often faster and cheaper. The trade-off is that nobody independent is reviewing the build. You can close that gap with simple habits: keep the code in your own repository, insist on working software every week, and consider an outside review before big moments such as a fundraise.