Fractional CTO: The First 90 Days

What the first 90 days of a fractional CTO engagement look like

A fractional CTO engagement lives or dies in the first 90 days. You started the subscription. The fractional CTO starts Monday. Now you're wondering what exactly this person is going to do all day.

It's a fair question. You're paying $5,499 to $9,499 a month for someone who isn't sitting in your office full-time. Unlike adding a full-time engineer to payroll, there's no six-month ramp-up period where you hope things work out. A fractional CTO engagement needs to produce visible results fast, or the subscription doesn't earn its keep.

To be clear about the commercial side: CTO Advisory ($5,499 a month) and Fractional CTO ($9,499 a month) are both month-to-month subscriptions, not fixed contracts. Both carry a fourteen-day money-back guarantee, and you can stop in any month with no exit fee. The 90-day structure below is the Fractional CTO version, the fuller engagement. CTO Advisory follows a lighter version of the same arc. Both are on the Fractional CTO page.

I've run this playbook across dozens of engagements over 17 years and 250+ projects. Some customers came to me with a codebase on fire. Others had no technical team at all, not even one person, and needed someone to build from zero. The specifics change. The structure of the first 90 days stays remarkably consistent.

Below is that structure, week by week. Whether you're evaluating a fractional CTO right now or you've already started a subscription and want to know if things are on track, this is the framework I use.

A 2024 Stack Overflow Developer Survey ranked unclear requirements and missing technical leadership as two of the top reported drains on engineering productivity. The first 90 days exist specifically to remove those two problems.

TL;DR

Days 1-30: Technical audit, risk assessment, stakeholder interviews, written strategy document. You should leave month one with a clear picture of where your technology stands and what needs to happen first.
Days 31-60: Execute on the highest-impact items. Fix security gaps, reduce infrastructure costs, establish development processes, start building the team if needed.
Days 61-90: Build sustainable systems. The CTO role should start running on its own momentum with documented processes, a functioning team, and measurable KPIs (the numbers that tell you if things are working).
The first 30 days are about listening and diagnosing. Founders who push for immediate code changes before the audit is finished usually regret it.
A good fractional CTO engagement pays for itself within 90 days through cost savings, avoided mistakes, or faster time to market.

Write to me. I answer within 24 hours, every working day, in writing.

Send a message ›

Before day one: setting the engagement up right
Days 1-30: the diagnostic phase
Days 31-60: the execution phase
Days 61-90: building for the long term
What a fractional CTO does NOT do
How to measure if it's working
Reflecting on what makes 90 days enough
FAQ

Before day one: setting the engagement up right

The fractional CTO engagement actually starts before the first official day. There's a scoping conversation that determines everything else.

In my practice, this looks like a 60-90 minute call where I ask three categories of questions:

Business context. What's the revenue model? What stage are you at? What's the runway? Are you raising soon? These shape every technical decision. A company with 18 months of runway makes different architecture choices than one with 5 months.

Current technical state. Do you have a product? A dev team? A codebase? Any known shortcuts weighing things down? Any incidents or outages recently? I need to know what I'm walking into, and it's fine if the honest answer to some of these is no.

What "success" means to you. Some people want someone to manage an existing team. Others need help building an investor-ready tech strategy. Others need their API response times cut in half before a major customer launch. These are very different jobs, and the 90-day plan changes based on which one you need.

After this conversation, I send a one-page engagement brief. It outlines what we'll focus on, what I'll deliver by day 30/60/90, and how we'll communicate (weekly syncs, Slack, async updates).

This step matters more than most people think. I've seen fractional CTO engagements fail because nobody defined what "done" looked like. If both sides can't describe the win in writing, you're not ready to start.

Days 1-30: the diagnostic phase

The first 30 days are about listening, reading, and diagnosing. Not building. Not rewriting. Diagnosing.

I know this can feel slow to people eager to see code shipping. I've also learned the hard way that making changes before understanding the full picture creates more problems than it solves. Think of it like a doctor running tests before prescribing. You want the diagnosis to be right.

Week 1: stakeholder interviews and access

The first week is about people and access.

I schedule 30-minute conversations with everyone who touches technology: developers, designers, product managers, the founder, the sales team (they know which features customers are begging for), and support (they know what's breaking). At a small startup, that might be 4-5 conversations. At a larger company, 10-12. If there's no team yet, this becomes a single deeper conversation with you.

I'm listening for patterns. Where do the same complaints come up twice? What workarounds has the team built? What decisions were made under pressure that everyone knows are temporary but nobody has fixed?

Simultaneously, I'm getting access to everything. Codebase, cloud infrastructure (AWS, Google Cloud, Azure, or whatever you're running), monitoring dashboards, deployment pipelines, error logs, project management tool. If some of those don't exist, that's a finding in itself.

Week 2: technical audit

This is where I dig into the codebase and infrastructure. I'm evaluating:

Code quality. Is it maintainable? Could a new developer understand it in a reasonable amount of time? Are there tests?
Architecture. Does the system design match the current scale? Will it handle 10x growth, or will it break under load?
Security. Are credentials exposed? Is authentication handled properly? Is data encrypted? Are dependencies up to date?
Infrastructure costs. Are you paying for resources you're not using? Is the hosting setup reasonable for your traffic, or is it either over-provisioned or a ticking time bomb?
Shortcuts and messy patches. Every codebase has some. The question is whether they're manageable or actively slowing down development.

I've walked into codebases where the previous team stored passwords in plain text. I've found AWS bills that ran far higher than the traffic on the site ever justified. I've seen startups with zero automated tests shipping code directly to production on Fridays. Each of those is a different severity level, and the audit tells me where to focus first.

Week 3: competitive and market context

This is where having a CTO with business experience, not just technical skills, makes a real difference. I look at what competitors are building, what technologies they're using when that information is visible, and where the market is heading.

For one customer, this analysis revealed that several competitors had launched AI-powered features in the months before. Their product roadmap had no AI story at all. That realization shifted the entire technical strategy. Retrieval over a company's own documents, agents that take action, document extraction: this is scope I now handle inside the Applications subscription, always with an evaluation suite so the AI behavior is measured, not assumed.

I also evaluate the build vs buy question for key features. People often assume they need to build everything custom when an existing tool would solve most of the problem at a fraction of the cost. The right answer is rarely the most exciting one.

Week 4: strategy document delivery

By the end of month one, I deliver a written document. Not a slide deck with vague platitudes. A specific, prioritized document that covers:

Current state assessment with specific findings (not "the code needs improvement" but "the authentication module has three known vulnerabilities and no rate limiting").
Risk register ranked by severity and likelihood.
90-day roadmap with measurable milestones.
Resource plan. Who needs to join the team, what you can outsource, what tools to adopt or drop.
Budget implications. What this will cost and what it will save.

This document becomes the foundation for everything in months two and three. It's also something you can share with investors, co-founders, or a board.

I've had customers tell me this document alone was worth the first month's fee because it gave them clarity they'd been missing for a year.

Days 31-60: the execution phase

Month two is where things get tangible. The strategy document identified the priorities. Now I act on them.

One thing worth being direct about: Fractional CTO and CTO Advisory don't include writing production code myself. "Execution" here means directing the fixes, setting priorities, defining the technical approach, and reviewing the work as it happens, whether that's your existing team, contractors you bring on, or an Applications subscription running in parallel for the hands-on build work.

The specific work depends on what the audit found. It typically falls into four categories.

Fixing what's broken (security and stability)

If the audit found security vulnerabilities, those get fixed first. No exceptions. I've seen startups lose customers, face legal exposure, and blow fundraising rounds over security incidents that could have been prevented with a week of focused work. The OWASP Top Ten covers most of the categories I check against.

Common fixes in this phase:

Rotating exposed credentials and API keys.
Implementing proper authentication and authorization.
Setting up SSL/TLS (the padlock in the browser bar) if it's missing or misconfigured.
Adding basic monitoring so you know when something breaks before your customers tell you.
Establishing a backup and disaster recovery plan.

This is unglamorous work. It doesn't produce features your customers can see. It also prevents the kind of catastrophic failure that kills startups overnight.

Reducing infrastructure costs

Almost every customer I've worked with was overspending on cloud infrastructure. In the Cuez case study, that meant about 40% off the infrastructure bill, alongside an API that went from 3 seconds to 300ms. In the Imohub case study, infrastructure cost dropped 70%. The exact number depends on how the original setup was done, but that kind of savings often covers the subscription on its own.

Common wins:

Right-sizing servers (most startups provision for traffic they don't have yet).
Eliminating unused resources (that staging environment nobody's touched in 8 months).
Switching to reserved instances or savings plans for predictable workloads.
Moving static assets to a CDN (content delivery network, which serves files from servers closer to your users, making your site faster and cheaper to run).

Establishing development processes

If the team is shipping code without a proper process, month two is when that changes. This includes:

Version control workflows. Code changes are reviewed before they go live.
CI/CD (continuous integration and continuous deployment). Automated testing and deployment so bugs get caught before reaching production.
Code review standards. What a pull request should look like, who reviews it, how fast.
Documentation. Enough that someone new can set up the project and understand the architecture without a three-day onboarding session.

These process changes often meet resistance from developers used to moving fast without guardrails. The key is explaining the "why" in business terms. Code reviews catch bugs early, when they're cheap to fix, instead of after they reach production. Automated tests mean you can ship with confidence instead of crossing your fingers.

Building the team (if needed)

Many fractional CTO engagements include building or restructuring the technical team. Month two is when I start on this if the strategy document identified the need to add people.

I typically handle:

Writing job descriptions that attract the right candidates (most startup job postings are either too vague or read like a wish list for a unicorn).
Defining the technical interview process.
Screening resumes and conducting initial technical assessments.
Recommending whether to bring someone on full-time, part-time, or as a contractor, based on the workload and budget.

The decision between bringing on a full-time CTO and staying with a fractional one usually becomes clearer by the end of month two. Some companies discover they need a full-time senior engineer more than they need a CTO. Others realize the fractional model fits them well as they are. If you want the fuller comparison, see what a fractional CTO does.

Days 61-90: building for the long term

By month three, the fires should be out. The immediate risks are addressed. Costs are optimized. The team has a process that works. Now the focus shifts to sustainability.

Technology roadmap alignment

I revisit the 90-day roadmap created in month one and align it with the company's product goals for the next 6-12 months. This is where technical strategy meets business strategy:

Which features require new technical capabilities?
Where should we invest in scalability before it becomes urgent?
What technical partnerships or integrations would speed growth?
Are there opportunities to use AI to reduce manual work?

Team development

If new people have joined, month three focuses on getting them productive. I set up:

Onboarding documentation.
Mentorship pairings (if the team is large enough).
Regular one-on-one meetings between the tech lead and individual contributors.
A feedback loop so I know what's working and what isn't.

For existing team members, this is often when I address skill gaps. Maybe the team is strong on frontend work but weak on database optimization. Or they know how to build features but struggle with writing testable code. I create a targeted development plan rather than sending everyone to generic training.

Establishing KPIs and dashboards

You can't manage what you can't measure. By day 90, every engineering team I work with has a dashboard tracking:

Deployment frequency. How often the team ships code (weekly is healthy for most startups).
Lead time. How long it takes from "developer starts working" to "feature is live."
Error rates. Are bugs going up or down?
Infrastructure costs. Monthly spend with trend lines.
Uptime. What percentage of the time is your product available to users?

These aren't vanity metrics. They're the numbers that tell you whether your technology organization is healthy and improving. Founders who can see those numbers make better decisions about when to invest in engineering and when to hold back.

The DORA research program at Google Cloud has been publishing on a similar set of metrics for years. The exact thresholds change. The principle, measure then improve, does not.

The handoff plan

At the end of 90 days, we decide together what happens next. The options usually look like:

Continue the fractional engagement at the same or reduced cadence. This works well for companies that need ongoing strategic guidance but don't need, or can't justify, a full-time CTO.
Transition to a full-time CTO. I help recruit, vet, and onboard my replacement. I've done this multiple times, and I stay involved for 30 days after the transition to make sure it's smooth.
Scale down to CTO Advisory. The team is self-sufficient but wants a monthly check-in and someone to call when big decisions come up.

The worst outcome is option four: the engagement ends with no clear plan, and everything I built slowly erodes. That's why the handoff plan is non-negotiable in my practice.

What a fractional CTO does NOT do

Setting expectations matters. Here's what falls outside a typical fractional CTO engagement:

Write production code. That's not part of Fractional CTO or CTO Advisory. If you need dedicated engineering hours, that's what the Applications subscription is for: a first version in the first month, then ongoing feature work, integrations, and fixes. A CTO engagement and an Applications subscription solve different problems, and some customers run both. If you need 40 hours a week of code getting written, see subscribing to a build versus adding a full-time engineer.

Replace an existing team. A fractional CTO makes the people already there better. If a full rebuild is what's needed, that's a different, and longer, conversation.

Make decisions in a vacuum. I bring recommendations. You bring business context and final authority. The best engagements are collaborative, not dictatorial.

Guarantee specific outcomes when the variables aren't in my control. I can guarantee a thorough audit, a clear strategy, and disciplined execution. I can't guarantee your product will hit product-market fit, because that depends on factors beyond technology.

How to measure if it's working

By day 30, you should be able to answer "yes" to these questions:

Do I understand my technical risks and how severe they are?
Do I have a written, prioritized plan for the next 60 days?
Has the CTO talked to every relevant stakeholder?

By day 60:

Are the highest-risk items resolved or actively being resolved?
Has infrastructure spending decreased or been justified?
Does the team have a defined development process?
If we needed to add people, is that process started?

By day 90:

Can I see a dashboard with our key engineering metrics?
Does the team feel more structured and productive?
Do I have a clear recommendation for what the next 6 months look like?
Is there a documented plan if the fractional CTO leaves?

If most of those answers are "no" at their respective milestones, something is wrong with the engagement. Have the conversation early. The cost of confronting an off-track engagement at week 4 is small. The cost at week 12 is much larger.

Reflecting on what makes 90 days enough

The 90-day window isn't arbitrary. It's how long it takes for one person to go from outsider to embedded team member, from observer to operator, from "the new consultant" to "the person we ask first."

Anything shorter and the audit is still landing when the engagement ends. Anything longer without measurable progress and you're paying for a continuation rather than a transition.

The best engagements I've run had clear endings written into them from the start. Not because either side wanted to leave, but because both sides knew what success looked like and could tell when it had arrived. That's harder to design than it sounds. It's also the difference between a 90-day plan that ships and a 90-day plan that quietly slides into month four.

If your engagement doesn't have a defined ending, ask for one. If it doesn't have measurable milestones at 30, 60, and 90 days, ask for those too. The answers will tell you whether you've brought on a strategist or someone who's hoping you'll forget to look at the calendar.

FAQ

What does a fractional CTO do in the first week?

A fractional CTO spends the first week interviewing stakeholders, getting access to code and infrastructure, and learning the business context. There should be no code changes or major decisions in week one. The goal is gathering enough information to form an accurate diagnosis of where the technology stands.

How many hours per week does a fractional CTO work?

Most fractional CTO engagements run 15-25 hours per week, depending on scope. During the first 30-day diagnostic phase, expect closer to 20-25 hours as the CTO conducts interviews and audits. After month one, the hours often settle into a consistent weekly rhythm based on the specific needs identified.

How is a fractional CTO engagement different from consulting?

A consultant typically delivers a report and leaves. A fractional CTO embeds with the team and stays to execute. They attend standups, review code, interview candidates, and own outcomes over months. The accountability and continuity are what separate the two models. You're getting a team member, not a vendor.

When should I switch from fractional to full-time CTO?

Consider a full-time CTO once the engineering team grows past a handful of people, product development becomes the primary business activity rather than something supporting it, and the annual technology budget moves well into six figures. Below those thresholds, a fractional CTO typically delivers better value per dollar spent.

Can a fractional CTO help with fundraising?

Yes. Many investors want to see a credible technology leader on the team. A fractional CTO can prepare technical due diligence materials, present the architecture and roadmap to investors, and answer technical questions during the fundraising process. This is a common part of the first 90-day engagement.

What happens next

The first 90 days set the direction for everything that follows. A well-run fractional CTO engagement gives you clarity about your technical risks, a plan you can actually execute, and steady improvement in how the technical side runs.

If you're at the point where you know you need technical leadership but aren't sure a full-time position makes sense yet, a 90-day fractional engagement is a low-risk way to find out. You get the strategic thinking and execution without the full annual cost of adding someone full-time to payroll.

I've been doing this for 17 years across 250+ projects. If you want to see what the first 90 days would look like for your situation, you can start on CTO Advisory or Fractional CTO and find out directly, backed by the fourteen-day money-back guarantee and the option to stop in any month.

The Fractional CTO Engagement: What Actually Happens in the First 90 Days