What Does a Fractional CTO Actually Do? A Week-by-Week Breakdown

The question comes up at the end of almost every intro call, right before pricing:

"So what do you actually... do? Like in a typical week?"

It's the right question, and the vagueness of most answers is part of why fractional CTO engagements either work extremely well or produce expensive disappointment. The title covers an enormous range: from high-priced advisors who show up for a monthly one-hour call to fully embedded technical leaders who function as de facto CTOs in all but name and salary.

Understanding exactly what the engagement looks like — before you sign anything — is the difference between buying the right thing and buying something that sounded like the right thing.

What a Fractional CTO Is Not

Before the week-by-week, the things that frequently get assumed but are wrong:

Not a part-time software developer. A fractional CTO isn't hired for their coding capacity. They might review code — almost certainly will — but they're not the person writing the next feature. If your problem is that the team doesn't have enough engineering bandwidth, a fractional CTO doesn't solve it. Contractors or a permanent hire does.

Not an emergency firefighter. If production is down this week and you need someone to fix it urgently, a fractional CTO engagement (which typically starts with a 1–2 week audit before any operational work begins) is the wrong fit for that immediate moment. Hire a senior contractor to handle the crisis. Then bring in a fractional CTO once the fire is out and you're ready to address the structural problems that caused it.

Not an occasional advisor. Monthly advisory calls are sometimes called "fractional CTO" work. They're not. An advisor gives you one perspective per month. A fractional CTO is embedded in your team — present in standups, reachable in Slack, reviewing code, doing interviews. The difference in outcome matches the difference in involvement.

Not a co-founder. No equity (unless negotiated separately), no decision-making authority that overrides the founders, no long-term operational commitment beyond the retainer term. A fractional CTO operates within the company's existing authority structure. They advise and guide; you and your leadership team decide.

Month 1: The Audit

Every well-run fractional CTO engagement starts the same way — not with operational work, but with a structured technical audit. This is the most important artifact of the entire engagement. If month 1 doesn't produce a written audit document, something has gone wrong.

What the audit covers:

• Codebase quality. Architecture, test coverage, dependency health, security posture, technical debt concentration. Not a line-by-line review — a structural assessment. Where are the chokepoints? What breaks when one developer leaves?
• Infrastructure. How the system is deployed, what the failure modes are, whether backups exist and have been tested, current operational costs, alerting and monitoring gaps.
• Team skills and structure. Who is on the team, what each person is strong and weak in, where the key-person risks are, how the team is organized relative to the work they're doing.
• Development process. How work gets planned and prioritized, how code review happens, how releases happen, what's working and what isn't.
• Immediate risks. The two or three things most likely to cause a serious problem in the next 90 days if left unaddressed.

What the audit produces:

A written document — 5–15 pages depending on the complexity of the system — covering each of the above areas with specific findings, prioritized recommendations, and realistic effort estimates. This document is yours at the end of month 1, regardless of whether the engagement continues.

The prioritization is the most valuable part. Not a list of everything that should eventually be fixed — that list is always too long to act on. A ranked list of the three to five interventions that will have the highest impact on velocity, reliability, or scalability.

What the Hours Look Like (By Retainer Size)

The three retainer tiers map to genuinely different involvement levels, not just different prices.

Advisory tier — 8–10 hours/month

This is a sparring partner, not an operator. The engagement looks like:

• Weekly 1-on-1 strategy call (60 minutes): agenda driven by whatever architectural, hiring, or process decisions need a senior perspective that week
• Async availability (2–3 hours/week): questions over Slack or email, quick reviews of documents or proposals, short code-review comments on critical changes
• Architecture review when needed: if you're about to make a significant technical decision, the fractional CTO reviews it before you commit

What you don't have at this tier: attendance in daily standups, systematic code review, hands-on hiring involvement. This tier is appropriate when your main issue is decision-making quality — you have a capable team and you need a senior technical thinker to pressure-test the important choices.

Active CTO tier — 20–25 hours/month

This is the most common engagement. The fractional CTO is operationally present, not just advisorily present.

A typical week at this tier:

The total comes out close to 5–6 hours per week — present enough to have real context, not present enough to be a permanent team member.

What this tier produces over three months: a technical audit (month 1), a prioritized improvement roadmap, improvements visible in team velocity, a working code review culture, and — if you were hiring — better hires.

Full Engagement tier — 35–40 hours/month

This is CTO-in-all-but-name. Daily availability, leadership of the technical team, full decision authority on architecture and hiring, direct management of engineers if needed.

This tier is appropriate as a bridge: when you've lost your CTO and need continuity while hiring a replacement, or when the company has grown to a scale where the previous arrangement (a strong individual contributor doubling as technical leader) is genuinely breaking.

I've been on the inside of a product that hit that threshold — FutureAngel outgrew what a two-person technical team could sustainably run alongside other commitments, and we made the deliberate decision to hand it off to the design partners rather than stretch until something broke. That experience of watching scope outpace leadership capacity is a lot of why I'm specific about when this tier applies and when it doesn't.

At this tier, the fractional CTO is effectively a team member who happens to not be on permanent payroll.

The Artifacts You Should Have at the End of Each Month

This is the clearest accountability mechanism in a fractional CTO engagement: what concrete things exist at the end of each month that didn't exist before?

End of month 1:

• Written technical audit with prioritized findings
• List of immediate risks with mitigation steps
• Initial recommendation for 90-day improvement plan

End of month 2:

• 90-day technical roadmap with specific milestones
• Architecture decision records for any significant decisions made
• Code review norms documented (what gets reviewed, by whom, to what standard)
• If hiring was in scope: job description, technical interview process, evaluation rubric

End of month 3:

• Progress update against the 90-day roadmap
• Team skills assessment (individual strengths, development areas, key-person risks)
• Updated risk register (what was fixed, what remains, what's new)
• Recommendation for what the engagement should focus on in months 4–6 (or whether it should end)

If any of these artifacts are missing at the stated intervals, ask for them explicitly. They're not optional deliverables — they're how you verify the engagement is producing value and not just hours.

The One Thing That Kills Fractional CTO Engagements

It isn't a bad fractional CTO. It's a lack of authority to act on findings.

The audit will surface things that need to change: a part of the codebase that's too risky to keep building on, a hiring process that keeps producing bad fits, a deployment process that makes every release a weekend event.

Acting on those findings requires organizational will — the founder's buy-in, budget, team time, and sometimes difficult conversations with people currently doing things the wrong way.

A fractional CTO who finds problems but can't get anything changed will eventually stop being useful. Not because they stopped working — because the organization stopped listening.

The fractional CTOs who produce the most visible impact are the ones who have a direct line to the founder, are in the room for relevant decisions, and have explicit agreement upfront on what their findings obligate the company to address.

If you're bringing in a fractional CTO, make sure the mandate is real — not just advisory. If it's purely advisory, calibrate your expectations accordingly.

What the End of the Engagement Should Look Like

A good fractional CTO engagement ends with the work landing somewhere, not just expiring.

By the end of a 3–6 month engagement:

• The audit findings should be addressed or explicitly deprioritized with a documented rationale
• The team should be more capable than it was — code review culture, better interviews, fewer ad-hoc architecture decisions
• Architecture decision records should exist for the major choices made during the engagement
• Whoever inherits the technical leadership (a new full-time CTO, an elevated engineering lead, or the founder) should have a clear written handover document

If the engagement ends and the knowledge lives only in the fractional CTO's head, that's a failure of delivery — even if the individual months felt productive.

Make documentation an explicit deliverable from the start, not an afterthought at the end.

For details on how I run fractional CTO engagements — scope, retainer pricing, initial audit, and the 30-day notice model — see the Fractional CTO service page.

Written by Alex Kadyrov, an independent software engineer based in Dubai. I help startups and growing businesses with AI solutions, MVP development, and fractional CTO engagements.