Founders ask me this question in two ways. Some ask whether they can justify the cost yet. Others ask whether they have a problem they cannot see.
The second question is the right one. The first is how the decision usually gets delayed.
Thresholds are the wrong instrument
The advice in circulation tends to attach a number to the answer. Hire one once you pass a certain headcount. Once you raise a particular round. Once revenue clears some line.
I would not decide this way, because the number describes the company's size rather than its exposure. I have seen a team of five where nobody could say which of their dependencies would fail under load, and a team of forty running perfectly well on a founder's instincts and a good lead engineer.
Size tells you how much technology work is happening. It does not tell you how many consequential decisions are going unmade.
That is the thing worth measuring.
Five signals that the moment has arrived
None of these is fatal on its own. Two together usually mean the conversation is overdue.
The founder is still the default CTO, and it is costing the company the work only they can do. This is the most common and the most expensive. A technical founder is often perfectly capable of leading the technology function. The question is whether that is the best use of the one person who can raise the next round, close the strategic customer and decide what the company is for. When architecture reviews are displacing those, the arrangement has stopped paying.
A strong engineering team has no executive technology leadership above it. Capable engineers with no senior technology voice in the room will optimise for what they can see. They will build well and they will build the wrong things, because nobody is connecting their work to where the business is going. This failure is quiet and it compounds.
Growth is exposing gaps in architecture, delivery or organisation. Not outages. Outages are obvious. I mean the softer signals: estimates drifting, the same component appearing in every incident, a release process that everyone works around, new joiners taking a quarter to become productive.
The board is asking questions the company cannot answer well. If technology reporting is a status update rather than a view of performance, cost and risk, the board is making investment decisions on partial information. That gap usually surfaces at the worst moment, which is during diligence.
Something large is coming. Fundraising, market expansion, a platform change, a first enterprise customer with a security questionnaire. Each of these audits your technology function whether you are ready or not. The time to find the gaps is before someone else does.
When it is genuinely too early
I turn down more of these conversations than founders expect, because bringing in senior technology leadership at the wrong moment wastes money and, worse, slows a team down.
It is too early when you have not found the shape of the product yet. Before that point, the right technology strategy is usually to build the cheapest thing that answers the question in front of you, and senior architectural judgment applied to a product that is about to change completely is judgment spent on nothing.
It is too early when the founder is technical, has the time, and is enjoying it. That arrangement works, and it works for longer than most advice admits. Replace it when it stops working, not when a blog post says you should.
It is too early when the real problem is that you need to hire two more engineers. Leadership does not substitute for capacity. If the team is simply too small for the work, adding a part-time executive above them makes the ratio worse.
And it is the wrong arrangement entirely if the situation is a crisis rather than a gap. A company whose delivery has broken, whose platform is unstable, or whose CTO has just left needs someone holding the role, not advising it. That is interim work, and the distinction matters more than most founders realise.
What the first ninety days should look like
If you do bring someone in, it is worth knowing what good looks like, so you can tell early whether it is working.
The first weeks should be spent establishing the truth rather than proposing solutions. Anyone arriving with a strategy in month one is selling you a strategy they had before they met you. What they should be doing is reading the code, the incidents, the roadmap and the contracts, and talking to the engineers who have stopped expecting anyone to ask.
By the end of the first month, you should have an honest account of where you actually stand, including the parts you suspected and the parts you did not.
By the end of the second, that should have narrowed to the few decisions that will materially change the outcome. Not a list of everything wrong. A short list of what matters.
By the third, those decisions should be turning into sequenced work with owners and measures, and the team should be able to describe the plan without help.
If month three still looks like month one, the arrangement is not working, and you should say so.
The question behind the question
Almost every founder who asks me when to hire a fractional CTO is really asking something else: whether the technology decisions being made right now are good ones, and whether they would know if they were not.
That is a reasonable thing to be uncertain about. It is also answerable in a single conversation, which is considerably cheaper than a quarter spent wondering.
What complicates the timing now is that the role itself is changing. What a technology leader is accountable for looks different once intelligence is part of the product, the platform and the workforce, and hiring against the old description is its own kind of delay.