Skip to main content

What a Fractional CTO Actually Does in the First 90 Days

Most fractional CTO content explains what the role is and what it costs. Almost none of it describes the engagement — what actually happens after you sign, in what order, and what you should be holding at the end of it. This is that: the first 90 days phase by phase, the artifacts you should own by the end, and the early signals that tell you the engagement is drifting.

Founders researching a fractional chief technology officer (CTO) can find out what the role is, roughly what it costs, and how it compares to a full-time hire. What they usually cannot find is the thing they actually want to know before signing: what happens in the first three months, in what order, and what will I be holding at the end of it.

That gap matters, because the failure mode of a fractional engagement is rarely a bad hire. It is a good operator with no agreed shape to the work — three months of helpful conversations, no artifacts, and a founder who cannot tell whether it worked. The engagements that succeed look remarkably similar to each other, and they are structured from day one.

This is that structure: what a competent fractional CTO does across the first 90 days, what you should own at the end, and the early signals that it is drifting.

The first 90 days of a fractional CTO engagement broken into three phases: days 1 to 30 assessment, days 31 to 60 stabilise and decide, days 61 to 90 build the operating rhythm, with the artifacts delivered in each phase

Days 1–30: what is actually true here?

The first month is not for building. It is for replacing your assumptions with facts, because almost every founder brief contains at least one belief about the system that turns out to be wrong.

The technical audit

What exists, what state it is in, what is holding it together. Not a code-quality opinion — a risk map. Where is the single point of failure, what happens if the one engineer who understands billing leaves, what is the actual deployment process when it is 6pm on a Friday.

The people read

Who is on the team, what they are actually good at, who is quietly carrying the system, and who is blocked. This is usually where the biggest surprises are. A team described as "two senior engineers" often turns out to be one senior engineer and one person who has been left to sink.

The delivery reality

How work gets from idea to production today, and how long that genuinely takes. Founders tend to quote the fast case from memory. The useful number is the median, measured from the last ten things that shipped.

The spend picture

Infrastructure, tooling, vendors, and anything with a per-seat or per-token meter attached. This is frequently where the fastest measurable win of the whole engagement is sitting, untouched, because nobody senior has looked at the bill line by line.

What you should have by day 30: a written assessment with a risk register, an honest delivery baseline, and a prioritised list of what to fix — with the reasoning visible, not just the conclusions. If month one ends with a conversation instead of a document, that is your first warning sign.

Days 31–60: stabilise, then decide

Month two is where a fractional CTO earns the fee, because it involves saying no to things and being right about it. Two workstreams run in parallel.

Stop the bleeding

Whatever from the risk register is both high-impact and cheap to fix gets fixed now. Typically: deployment that a second person can run, backups that have actually been restored from once, access and credentials brought under control, monitoring that pages a human when it matters. None of this is glamorous. All of it is what stops a bad week becoming a bad quarter.

Make the decisions that are being avoided

Every stalled engineering organisation has two or three unmade decisions sitting underneath it — rewrite or extend, this platform or that one, hire or outsource, keep supporting the enterprise customer's custom fork or not. They persist because they are genuinely hard and nobody has both the authority and the context to close them. A fractional CTO's real value is often here rather than in the code.

The framing that works: make the decision reversible where you can, and where you cannot, write down what you decided and what would change your mind. That single habit prevents the same debate resurfacing every quarter.

What you should have by day 60: the top risks closed or explicitly accepted, the two or three big decisions made and documented, and a delivery process that a new engineer could follow without being told. This is also the point where our comparison with a full-time CTO becomes a real conversation rather than a hypothetical one, because you now know the size of the job.

Days 61–90: build the rhythm that outlasts the engagement

The third month is about making the improvement survive the fractional CTO leaving. An engagement that ends with everything depending on the fractional CTO has failed, however good the work was.

What a founder should own at the end of a 90-day fractional CTO engagement: technical assessment and risk register, documented decisions, a repeatable delivery process, a hiring plan with role definitions, a technical roadmap and an owned operating cadence

The operating cadence

Planning, review and escalation that happen on a schedule rather than when something breaks. Deliberately boring, and the thing most likely to still be running a year later.

The hiring plan

If the team needs to grow, month three defines what to hire, in what order, and what "good" looks like for each role — including who interviews and how. Founders hiring engineers without this end up hiring people who look impressive rather than people who fit the gap.

The roadmap that survives contact

Not a feature list. A sequence with dependencies and stated assumptions, so that when reality intervenes — and it will — the team can re-plan instead of freezing.

The handover

Whether the engagement continues, converts to a full-time hire, or steps down to advisory, month three should leave the knowledge outside the fractional CTO's head. Written, in your repository, in your language.

What you should have by day 90: the assessment, the decision record, a repeatable delivery process, a hiring plan, a sequenced roadmap, and a cadence your team runs without prompting. Six artifacts you own, not six months of goodwill you rent.

What changes when the company is building with AI?

An AI-first company does not get a different 90 days, but four things inside it carry far more weight, and a fractional CTO who treats them as ordinary engineering decisions will cost you money.

Model and vendor decisions are cost decisions

Choosing a model is not like choosing a framework. It has a per-token meter attached, and the difference between a considered choice and a default one shows up on the invoice every month, compounding with usage. Part of the month-one spend review in an AI company is working out what each feature costs per use, which is a number most teams have never calculated.

Evaluation has to exist before the roadmap does

A team shipping AI features without an evaluation suite is shipping changes it cannot measure. Every subsequent decision — better model, cheaper model, new prompt, new retrieval strategy — becomes a matter of opinion. Establishing how quality is measured is usually a month-one or month-two item, and it unblocks everything after it.

Build versus buy resets constantly

In conventional engineering, a build-or-buy call holds for years. In AI, the capability you built in-house six months ago may now be a commodity endpoint, and the thing you bought may now be worth owning. A fractional CTO should be re-examining these, not treating past decisions as settled.

Governance arrives whether you planned for it or not

Logging, data lineage and human oversight are increasingly obligations rather than good practice, and they are the artifacts that cannot be produced retroactively — a theme we cover in depth in our guide to the EU AI Act for engineering teams. A fractional CTO in an AI company should be asking about them in month one, when they are cheap, rather than month twelve, when they are a project.

If most of your engineering risk sits in this territory, an architecture audit is often a faster and cheaper first step than a full engagement — it answers the "how bad is it" question in weeks rather than months, and it tells you whether you need a fractional CTO at all.

Who needs to be available on your side?

The most common cause of a disappointing engagement is not the operator. It is that nobody internally had time for them.

A fractional CTO needs a founder or executive who can make commercial trade-off calls within a few days rather than a few weeks, because most technical decisions of any size are really business decisions wearing technical clothes. They need direct, unsupervised access to the engineers, or the assessment is just the founder's view of the team repeated back. And they need someone who will still be there afterwards to own the cadence, whether that is a lead engineer, a technical product manager or you.

If none of those three exist, delay the engagement rather than spending three months producing documents nobody has the authority to act on.

Is a fractional CTO the right call for you?

The engagement above is worth buying in some situations and a waste of money in others. The honest split:

Choose a fractional CTO if:
- You have engineers but no one setting technical direction
- You are making decisions with six-figure consequences on instinct
- You need senior judgement for a defined period, not forty hours a week forever
- You are pre-Series A and a full-time CTO salary would distort the whole budget

Choose a full-time CTO if:
- Technology is the product and the roadmap needs an owner in every conversation
- You are scaling headcount fast enough that hiring is a full-time job by itself
- You need someone accountable in the room with customers, investors and the board
- The engineering organisation is already large enough to need day-to-day leadership

Choose neither yet if:
- You have no engineers and no product — you need builders first
- The real problem is that nobody has decided what the company is
- You want someone to validate a decision you have already made
- Nobody internally has time to work with them, because a fractional CTO with no counterpart achieves very little

For the cost side of this decision, our fractional CTO pricing guide and the USA cost breakdown cover the ranges; the non-technical founder guide covers the case where you cannot personally assess the work.

What does this cost, and what should be in the agreement?

Our own fractional AI-first CTO engagements run $5,000–$15,000 per month, with the band set by scope, team size and how much of the work is decision-making versus hands-on. Market rates vary widely — the guides linked above cover the comparison — but the number matters less than what the agreement actually specifies.

Four things belong in it. The time commitment, in days per month rather than a vague retainer, because "part-time" means different things to different operators. The artifacts, named — assessment, decision record, roadmap, hiring plan — so that delivery is checkable rather than felt. The decision authority: what they can decide alone, what needs you, what needs the board; ambiguity here is the most common reason engagements stall. And the exit, including what handover looks like and who owns the documentation, which should obviously be you.

Notice that three of those four are about clarity, not price. Engagements that go wrong almost always go wrong on scope and authority, not on rate.

What are the early signs it is not working?

You do not need to wait 90 days to know. Four signals show up in the first month.

  • No written output by day 30. Plenty of good meetings, nothing you could hand to someone else. Verbal-only engagements leave nothing behind when they end.
  • They have not spoken to your engineers alone. Anyone assessing an engineering organisation only through the founder is assessing the founder's view of it, which is precisely the thing that needed checking.
  • Everything is a rewrite. An operator who recommends rebuilding before understanding why the current system is the way it is has substituted a preference for a diagnosis. Sometimes a rewrite is right, but it is a conclusion, not an opening position.
  • No decisions are being closed. If the same questions are open at day 45 as at day 5, you have bought advice rather than leadership. The role exists to close things.

Any one of these is a conversation, not a cancellation. All four together means the engagement is not going to produce anything you can keep.

Frequently asked questions

How many days a month does a fractional CTO actually work?

Commonly somewhere between two and eight days a month, depending on the stage of the engagement. Front-loading is normal and sensible: the assessment phase needs more contact time than the steady state that follows. What matters is that the commitment is written in days rather than described as "part-time", so both sides can tell whether it is being met.

Can a fractional CTO manage my existing engineers?

Yes, and in most engagements they should — technical direction is difficult to provide without any relationship to the people executing it. What varies is line-management responsibility. Some engagements include performance and career conversations, many do not. Settle it explicitly at the start, because engineers reporting to someone who is present four days a month need to know who owns their progression.

What happens after the first 90 days?

Three normal paths: the engagement continues at a lower intensity with the cadence established; it steps down to advisory while an internal lead takes over; or it converts to a full-time hire that the fractional CTO helps you recruit. All three are healthy. The unhealthy version is an open-ended engagement with no change in shape after a year, which usually means knowledge stayed with them rather than transferring to you.

How is a fractional CTO different from a technical consultant?

A consultant analyses and recommends; a fractional CTO decides and owns the outcome. That distinction sounds academic until a hard call has to be made about architecture or a person, at which point it is the whole difference. If your agreement gives them no authority, you have hired a consultant regardless of the title on the invoice.

Is a fractional CTO worth it for a pre-revenue startup?

Sometimes, and the test is whether you have engineers. If you have a team producing work with nobody setting direction, senior judgement pays for itself quickly. If you have no engineers and no product yet, you need builders first — a fractional CTO with nothing to direct is an expensive way to get a roadmap document.

What should I have at the end of the engagement?

Six artifacts, all of them yours: the technical assessment with its risk register, a record of the decisions made and the reasoning behind them, a repeatable delivery process, a hiring plan with role definitions, a sequenced technical roadmap, and an operating cadence your team runs without being reminded. If the engagement ends and none of that exists in writing, you rented opinions.


Need a technical leader without the full-time hire?

We run fractional AI-first CTO engagements on exactly the shape above — assessment first, decisions closed, artifacts you keep. Tell us where the engineering organisation currently hurts and we will tell you whether this is the right answer for you, including when it is not.

Scope a fractional CTO engagement →

Prefer to ask one question first? Send it here →


Related Services


Further Reading

Fractional CTO pricing guide Fractional vs full-time CTO For non-technical founders Best fractional CTO services

Ship 10-20X Faster with AI Agent Teams

Our AI-First engineering approach delivers production-ready applications in weeks, not months. AI Sprint packages from $15K — ship your MVP in 6 weeks.

Get Free Consultation

Was this article helpful?

Krunal Panchal

Written by Krunal Panchal

Groovy Web is an AI-First development agency specializing in building production-grade AI applications, multi-agent systems, and enterprise solutions. We've helped 200+ clients achieve 10-20X development velocity using AI Agent Teams.

Ready to Build Your App?

Get a free consultation and see how AI-First development can accelerate your project.

1-week free trial No long-term contract Start in 1-2 weeks
Get Free Consultation
Start a Project

Got an Idea?
Let's Build It Together

Tell us about your project and we'll get back to you within 24 hours with a game plan.

Schedule a Call Book a Free Strategy Call
30 min, no commitment
Response Time

Mon-Fri, 8AM-12PM EST

4hr overlap with US Eastern
247+ Projects Delivered
10+ Years Experience
3 Global Offices

Follow Us

1-week risk-free trial — keep the code

Hire Senior AI Engineers
Production-Grade. Your US Hours.

For startups & product teams

One senior engineer, AI-accelerated — owns architecture, security, and the last 20% AI tools leave broken. No recruitment, no ramp-up.

Trusted by 200+ startups worldwide

Production-grade delivery
4hr live US overlap
Start in 48 hours

No long-term commitment · 100% IP yours · Cancel anytime