The first 90 days with a fractional CTO: a realistic plan

A realistic plan for a fractional CTO's first 90 days has four phases. Days 1 to 14: access, audit, risks and quick wins. Days 15 to 30: a roadmap you can budget around. Days 31 to 60: a weekly delivery rhythm, first releases and a hiring plan. Days 61 to 90: measurable outcomes and the big decisions.

The dates aren't magic. A company with an idea and no code moves through these phases differently from one with a three-year-old platform and an unhappy agency attached. The order holds, though: understand before you change anything, plan before you build, and prove the rhythm before you scale it.

The 90-day plan at a glance

How long the first two phases take depends on what already exists. In my own engagements, discovery is a two-week sprint whose output (roadmap, architecture, estimate) becomes the plan, so phases one and two overlap. On a large existing system with a team and several vendors, expect the roadmap to take closer to the full month.

Days 1 to 14: access, audit and quick wins

The first two weeks are about seeing the real situation. Nothing gets rewritten, nobody gets hired or fired, and the stack doesn't change. A new CTO who starts redesigning everything in week one is guessing.

Get access to everything

Day one shouldn't be spent waiting for passwords. Your fractional CTO needs at least read access to the code repositories, cloud and hosting accounts, the domain registrar and DNS, app store accounts, databases, error tracking and analytics, the issue tracker, and vendor contracts and invoices. Each account goes into an access inventory with its owner. If the owner is "the agency" or "a developer who left last year," that goes straight onto the risk list.

Audit what exists

For a product that's already live, the audit covers five areas:

• Code: structure, tests, how hard it is to change, obvious security problems.
• Infrastructure: where it runs, how it's deployed, whether backups exist and have ever been restored.
• Costs: cloud bills, licenses, subscriptions and vendor retainers.
• People and vendors: who knows what, who is contracted for what, and what each costs.
• Product: what users actually do, where they drop off, what support hears most.

If there's no product yet, the audit is lighter: the idea, any validation evidence, specs, designs, prototypes, quotes you've already received, and the constraints (budget, deadline, regulation).

Write the risk list

The most useful document from the first two weeks is a ranked list of what could hurt the business, each item with a proposed fix and a rough effort. Entries I come across again and again:

• The production database has no tested backups.
• The domain or the app store account is registered to the agency.
• Passwords and API keys sit in the code repository.
• Only one former developer knows how deployment works.
• The cloud bill has doubled and nobody knows why.

Ship two or three quick wins

Quick wins earn trust and cut risk at the same time. Good ones are small, safe and visible: turning on backups and testing a restore, moving accounts into the company's name, adding error monitoring, canceling unused subscriptions, fixing the bug customers mention most. Big features wait for the plan.

Days 15 to 30: the roadmap and the plan

With the facts in hand, the next two weeks turn them into a plan you can run the company on. By day 30 you should have:

• A roadmap for the next two quarters, written as outcomes ("clinic staff can manage bookings without calling us") rather than a feature wish list, and split into now, next and later.
• An architecture outline in plain English: the main parts, where the data lives, what's bought rather than built, and why.
• An estimate with ranges, not a single date, plus the assumptions behind it.
• A budget view covering build cost, running costs (hosting, tools, licenses) and team cost.
• A fix, refactor or rebuild call if the audit raised the question, with the reasoning. If the current build is in real trouble, this is where a rescue plan for a stalled project starts.
• Baselines for the numbers you'll judge progress by: release frequency, open bugs, incidents and monthly cloud spend.

Walk through it together, slowly. If you can't explain the roadmap and the top risks to an investor after that meeting, the plan isn't finished.

Days 31 to 60: delivery rhythm and first releases

Now the work shifts from planning to proving. The goal of this phase is a rhythm you can rely on, not a big launch.

1. Short cycles. Work is planned in one-week or two-week sprints, each with a clear goal.
2. A weekly demo. You see working software, not slides. If it can't be demoed, it isn't done. In my engagements, that is something runnable each week, shown in a Friday demo.
3. A short written update. What shipped, what's next, what's blocked and which decisions need you.
4. A release path. Changes go out through a repeatable process, with a way to roll back.
5. First releases to real users. Even small ones. Real usage settles arguments that internal opinions can't.
6. A hiring and vendor plan. Which roles you need, in what order and when, or whether contractors or the current vendor should carry the next stage.

Expect the first weeks of this phase to feel slower than you hoped. Setting up a proper release path and fixing the worst risks costs time up front, then pays it back every week after.

Days 61 to 90: measurable outcomes and decisions

By the third month there's enough evidence to judge progress. Compare against the baselines from the first month:

• Has the team shipped what the roadmap said, within the ranges given?
• Are releases more frequent, and are incidents and urgent bugs down?
• Is technology spend clearer, and lower where it should be?
• Are the top items on the risk list closed?

I cover the metrics and a simple monthly review in how to measure what a fractional CTO is worth. The other half of this phase is the decisions you have probably been putting off:

• Hire the first engineer now, later or not at all?
• Keep, change or drop the current agency or vendor?
• Scale the CTO's hours up, down or keep them as they are?
• Is the technology ready for an investor's scrutiny? If a raise is close, start working through a technical due diligence checklist now.

Close the phase with a written plan for the next 90 days. It will be shorter than the first one, because the unknowns are smaller.

What the founder should provide during the first 90 days

A fractional CTO works part-time, so a delay on your side costs more than it would with a full-time hire. Your part is smaller, but it often decides the pace:

• Grant access in the first two days, and say who owns each account.
• Share the history honestly: past vendors, failed attempts and why things are the way they are.
• Name one decision-maker, and answer blocking questions within a day or two.
• Keep the weekly demo slot, every week.
• Introduce the CTO to your team, your vendors and two or three real customers.
• Be open about runway, so the plan fits the money.
• Hold new feature ideas until the roadmap exists, then argue for them against it.

Your day-90 deliverables checklist

By day 90 you should be able to check off every item below. If you can't, ask why and agree on a date.

• An access inventory showing every account owned by the company, not a person or a vendor.
• Audit notes covering code, infrastructure, costs and vendors.
• A risk register with the top risks closed or scheduled.
• A written roadmap for the next two quarters.
• An architecture document a new engineer could start from.
• An estimate with ranges and stated assumptions.
• Tested backups and monitoring in production.
• A repeatable release process with a rollback path.
• Six or more weeks of weekly demos and written updates.
• Baseline and current numbers for releases, incidents and spend.
• A hiring and vendor plan with timing.
• A decision log of the main technical choices and the reasons for them.
• A written plan for the next 90 days.

Warning signs at the 90-day mark

Some engagements don't work, and 90 days is long enough to tell. Be concerned if:

• There's still no written roadmap, only conversations.
• You've seen progress reports but no working software.
• Everything has been "almost done" for weeks.
• You still can't explain your own architecture in two sentences.
• Accounts were set up in the CTO's own name.
• Every problem is the previous developer's fault, and nothing has been fixed.

Raise it directly first, because sometimes the cause is on your side: slow access, shifting priorities, a demo slot that keeps moving. If nothing changes, treat these as the same red flags you'd watch for when hiring, just showing up later.

The bottom line

A good first 90 days with a fractional CTO is boring in the best way: access in place, risks known, a plan you understand and working software every week. If you get there, the next 90 days are about speed. If not, you've found out at a reasonable cost. For how the wider engagement is set up, from engagement models to scaling hours and handover, see how a fractional CTO engagement works.