The first 90 days of a Fractional CTO engagement

Most founders, when they first ask about a fractional CTO engagement, ask the same question two different ways. First it’s “do I need one?” — which I’ve answered separately in fractional CTO vs full-time hire. Then, almost immediately, it’s “okay, but what do you actually DO?”

That second question is harder to answer abstractly. So I stopped trying. The most honest way I can describe the role is to walk through how the first 90 days actually unfold, because the 90-day onboarding is where the job becomes concrete. You see the codebase. You sit with the team. You touch the cloud bill. By the end of it, the founder either trusts the diagnosis enough to keep going, or doesn’t — and both outcomes are useful.

Here’s roughly how those 90 days look.

Weeks 1–2: Audit, not advice

The single biggest mistake a new fractional CTO can make is showing up in week one with opinions. You haven’t earned them yet. You don’t know which trade-offs the existing team has already debated, which constraints came from an investor call you weren’t in, or which load-bearing decision was made by someone who has since left.

So the first two weeks are diagnostic, not prescriptive. I ask for read-only access to the repo, read access to the cloud console, the vendor list, and the calendar. I sit in on standups without speaking. I do a 1:1 with every engineer — usually 30 minutes, sometimes longer if they want to vent — and I ask the same three questions: what’s the thing that’s been bothering you for months?, what would you fix if no one was watching?, and what do you wish the founder understood about the codebase?

Meanwhile I’m reading. A codebase tour: how is the repo structured, what’s the deploy pipeline, where are the obvious foot-guns. The infra: how many environments, what’s auto-scaled, what’s a single point of failure. The vendor list: every recurring spend, what each one is doing, who signed up for it.

At CryptoUnity the audit phase surfaced 32 security issues that had to be resolved before launch — none of which the team had been hiding, all of which were invisible from outside the code. That’s the value of weeks 1–2: you find the things nobody talks about because they’re not on fire today. The deliverable at the end of week 2 isn’t a strategy deck. It’s a written diagnosis. Bullet points. Brutally honest.

Weeks 3–4: Where the money’s going

Once the diagnosis exists, the second thing I look at is spend. Almost every startup I’ve audited had 30–60% waste in their dev tools, cloud, and SaaS subscriptions. Not because anyone was being reckless — because nobody had had the time to look at all of it at once, and individual line items always look reasonable in isolation.

The tactic is unglamorous: a single spreadsheet of every monthly recurring spend, tagged one of three ways. Critical — if this turned off tomorrow, the product breaks. Nice-to-have — useful, but we’d survive without it. Cancelled — paying for, not actually using, or replaceable by something already on the critical list.

This usually takes a working session with the founder and the senior engineer, because the founder knows what was promised commercially and the engineer knows what’s actually wired up. The output is a number: how much monthly burn we can recover in the next 30 days without breaking anything.

A small example: at Adriatic Investors we consolidated two sites onto one host during the engagement. Not a heroic architecture change — just one of those things that was obviously correct once both sites were owned by the same team, and that lowered the monthly bill immediately. Boring. Real money.

Weeks 5–8: The architecture conversation

By week 5, I have enough context to actually have an opinion. This is the part of the engagement where I earn my keep, and I try to be very deliberate about it, because architecture decisions made at pre-seed or seed are the ones founders refactor in pain at Series A.

The conversations in this window are the ones I lose sleep over:

• Monolith vs services. At your stage, almost always monolith. The team isn’t big enough to pay the operational tax of services, and the supposed scaling problem isn’t your real bottleneck.
• Build vs buy. Auth, billing, email, search — buy. The things that are your moat — build. Founders consistently get this backward and build the boring stuff because it feels like “real engineering.”
• What to migrate now vs leave alone. The temptation to rewrite is always there. Mostly the answer is: leave it, instrument it, only touch the parts that are blocking the next 12–18 months of product.
• Data model decisions. The single hardest category to undo. If we’re going to make a call I won’t regret in two years, this is where it lives.

At GetThrivin the engagement was a scaling-phase entry, which meant the architecture decisions weren’t theoretical — they were already shipping under real load. That’s a different flavor of the same conversation: less “should we?” and more “now that it’s broken under traffic, what’s the smallest correct fix?” Either flavor, the deliverable in this window is the same: a written architecture memo, with the decision, the trade-off, and the alternatives I rejected and why. Founders should be able to hand that memo to the next CTO and have them understand the call.

Weeks 9–12: Hiring readiness and handoff plan

By month three, the shape of the engagement has revealed itself, and it’s usually one of two shapes.

Bridge engagement. The fractional is a temporary fill for a full-time CTO who hasn’t been hired yet. In that case, weeks 9–12 are when I write the JD for the future full-timer, design the interview rubric, and draft the 30/60/90 plan they’ll execute when they join. I usually run the first two rounds of the recruiting loop with the founder, then step back as the offer goes out.

Permanent fractional. The founder has decided they don’t need a full-timer yet, and the engagement continues on a quarterly cadence. In that case, weeks 9–12 are when we lock the OKRs for the next quarter, agree on a weekly rhythm (standup attendance, architecture review cadence, board prep), and set the escalation rules — what gets a Slack message, what gets a same-day call.

Both shapes are valid. The founder picks based on what they actually need, not what sounds more impressive. I have a slight bias toward the bridge model because clean exits are healthier than open-ended retainers, but I’ve run plenty of permanent fractional engagements where the math just didn’t justify a full-time hire.

What’s NOT in the first 90 days

It’s worth being explicit about this, because expectations get set wrong.

• Not: writing production code. Sometimes I do, if there’s a very specific gap and it’s faster than briefing someone. But it’s not the job, and if I’m coding more than a few hours a week, something is mis-scoped.
• Not: replacing your senior engineer. A good fractional makes your senior engineer more effective, not redundant. If they feel undermined, the engagement will fail regardless of what I deliver.
• Not: a strategy presentation deck. I write memos. The medium matters — a deck is for selling, a memo is for deciding.
• Not: free advice on a discovery call. The engagement starts with a contract, a scope, and a baseline weekly-hours commitment. I’ll happily do a free diagnosis call, but the moment we’re actually working, it’s paid.

Close

90 days is the right shape for this kind of engagement because it’s long enough to actually diagnose — the team gets past the polite phase, the cloud bill arrives twice, the architecture stress-tests itself against a real sprint — and short enough to be reversible if the fit is wrong. Either of us can walk away at the end of it without scar tissue.

If you’re considering a fractional CTO engagement, book a free 30-minute diagnosis call. No pitch deck.