What a fractional CTO actually does in the first 30 days

The reasonable worry about hiring a fractional CTO is that you'll pay senior rates for someone who shows up two days a week, has opinions, and leaves. It's a fair worry. The engagement is short, the rate isn't small, and unlike an engineer there's no obvious artifact at the end of week one.

So here's what the first thirty days should actually produce. If you're evaluating someone — us or anyone else — this is a reasonable thing to hold them to.

Week one: inventory, not opinions

The first week is almost entirely listening, and anyone who arrives with a strong architectural opinion before it's over is guessing. There's a specific list to build:

• —Every system that exists, who built it, and whether anyone still understands it.
• —Where the code, the accounts, the domains, and the secrets actually live — and whose personal email owns them.
• —What breaks regularly, and what the team has quietly stopped reporting because nobody fixes it.
• —What the team believes it's building next, asked separately of each person. The variance in those answers is usually the finding.

That last one catches more than people expect. When a founder and three engineers give four different accounts of the next quarter, no architecture decision will fix it.

Week two: name the risks out loud

By the second week the inventory turns into a short written list of things that could hurt you, ordered by how badly and how soon. Not a strategy document — a list. Ours usually runs to a page.

The point of writing it down isn't ceremony. It's that unwritten technical risk gets rediscovered every few months by a different person, argued about, and deferred again. Written down and ranked, it either gets fixed or it gets a deliberate decision not to fix it. Both are fine. The loop is what costs you.

Most technical debt isn't a decision anyone made. It's a decision nobody finished making.

Week three: fix the one that's bleeding

There is almost always one thing actively costing money or time every week — a deploy process that takes a day, a manual step someone does every morning, an error nobody has read in months, a database with no backup anyone has tested restoring.

Fixing exactly one of them in the first month matters more than the list did. It demonstrates that the engagement produces change rather than analysis, and it usually pays for a meaningful share of the retainer on its own.

Week four: write it down and hand it over

The month closes with three artifacts, all of which belong to you and none of which require the fractional CTO to interpret:

• —A technical map — what exists, how it fits together, what it costs to run.
• —The ranked risk list, with what was fixed, what was deliberately deferred, and why.
• —A hiring view: which roles you need next, in what order, and what to ask candidates.

That third one is worth dwelling on, because it points at the exit. A fractional CTO engagement that isn't steadily making itself unnecessary has quietly turned into an expensive part-time hire.

What it shouldn't look like

A few honest failure signals, in case you're a few weeks in and uneasy:

• —A rewrite proposed before the end of month one. Nobody understands a system that fast, and rewrites are how consultants turn a retainer into a project.
• —New tools introduced before anything existing has been fixed.
• —Work happening in accounts you don't own, or that you'd lose access to if the engagement ended tomorrow.
• —No written output at all. If everything lives in calls, you're renting an opinion.

The shape of the thing

Thirty days should leave you with fewer unknowns, one fewer active problem, and a written picture of the technology that someone other than the author can act on. It should not leave you more dependent than you started.

If that's the sort of month you need, tell us where you actually are and we'll say plainly whether a fractional CTO is what you need — or whether it's a contractor, a hire, or nothing yet.