The First 90 Days of a Fractional CTO: A Week-by-Week Log From Three Real Engagements

What a fractional CTO actually does in the first 90 days

In the first 90 days a fractional CTO inventories access and spend, maps the systems that already exist, writes down the risks in a form a founder can act on, kills waste, and ships one small change to prove the deploy path works. What they do not do is rewrite, re-platform, or hire.

The reason the sequence matters is that almost every founder who hires fractional technical leadership is doing it after a gap, not before one. A contractor left. An agency wound down. A technical co-founder went part-time. The thing you inherit is not a clean brief, it is a set of running systems with undocumented owners. Any plan that starts with architecture opinions is skipping the step where you find out what you are actually allowed to touch.

The three engagements this log is drawn from were different in shape. One was a regulated diagnostics platform with a lab, physical kits, clinicians, and personal health data. One was a multi-sided marketplace with retailers, shoppers, drivers, and perishable delivery windows. One was a community fitness business that ran on spreadsheets before it ran on software. Different domains, near-identical first two weeks.

Weeks 1 and 2: read-only access inventory and the credential map

Weeks 1 and 2 are read-only. The output is a single document listing every system, who pays for it, whose name is on the account, who can deploy it, and what happens if that person is unreachable. No code is written, no opinions are given about the stack, and nothing changes except adding the fractional CTO as a viewer.

The findings repeat across engagements with unnerving consistency. An Apple Developer account registered to a contractor who had finished up eighteen months earlier, meaning no build could ship until the account was transferred. A cloud billing line, in one case document reads on a NoSQL database, that nobody internally could attribute to a feature, because the person who wrote the query had left. A production deploy path that existed only on one laptop, with credentials in a local environment file, which is a bus factor of one dressed up as a working process. Domain registrations on a personal email address. Two separate analytics vendors billing monthly for data nobody had opened in a year.

The discipline here is to resist fixing things as you find them. A half-fixed access map is worse than a complete unfixed one, because you lose the ability to hand the founder a single document that says: here is everything, here is what is fragile, here is the order we address it. Fixes start in week 3, after the founder has seen the whole picture and agreed the order.

• • Cloud and hosting accounts: owner of record, payer, billing alerts, who has console access
• • Source control: every repository, every collaborator, any repos outside the org account
• • App Store and Play Console: legal entity on the account, signing certificates, who can push a build
• • Domains, DNS, email, and TLS certificates: registrar logins and renewal dates
• • Third-party vendors: every recurring charge, what it does, last time anyone logged in
• • Deploy path: how a change reaches production today, and how many people can do it
• • Data: where personal data lives, what is exported where, and what retention exists
• • People: contractors with live access who are no longer engaged

Weeks 3 to 6: the first written artifacts

Weeks 3 to 6 produce four documents: a system map, a risk register ordered by blast radius, a spend review with cancellations recommended, and a hiring or not-hiring recommendation. These are written artifacts a founder can forward to a board member or an investor, not a verbal debrief that evaporates after the call.

The system map is deliberately boring. Boxes for every running system, arrows for every data flow between them, and a label on each arrow saying what moves and how often. In the diagnostics engagement that meant showing how a sample identifier travels from kit registration through the lab system to result release, and where consent state is checked along the way. In the marketplace engagement it meant drawing the six systems that exchange order, stock, and route data. Founders who have never seen their own architecture on one page usually correct it within ten minutes, which is exactly the point: the map is a conversation tool before it is documentation.

The risk register is sorted by blast radius, not by how much the risk annoys an engineer. A bus factor of one on deploys outranks inconsistent naming conventions. An unowned billing line outranks missing test coverage. Each item gets a one-line description, an impact if it happens, an owner, and a decision the founder needs to make, if any. The spend review is where the quickest wins live: duplicate monitoring tools, an unused staging environment running full-size instances, a support platform seat count that never came down after a team shrank. Three vendor renewals were cancelled across these engagements in this window, none of which required an engineering change.

• • System map: every running system, every data flow, on one page
• • Risk register: ordered by blast radius, each with an owner and a founder decision if one is needed
• • Spend review: every recurring charge with a keep, downgrade, or cancel recommendation
• • Hiring recommendation: which roles are real, which are a job description stitched from three roles

Weeks 7 to 12: the first shipped change and the first escalated decision

Weeks 7 to 12 are about proving the pipeline, not proving ambition. The first shipped change is chosen because it is small, reversible, and touches the deploy path end to end. The second output is the first genuine escalation: a decision the founder has to make, presented with options, costs, and a recommendation rather than a question mark.

Good first changes look unglamorous. Moving deploy credentials off one laptop into CI and having someone other than the original owner run a release. Adding a billing alert with a threshold the founder chose. Fixing the one database query responsible for a disproportionate share of reads, which is a cost change disguised as a code change. Transferring the App Store account to the company entity and re-signing a build. Each of these is measured in hours, not sprints, and each removes a specific line from the risk register.

The first escalation is usually a spend or a dependency question. Do we renew the vendor whose contract expires in six weeks, at a higher tier, or migrate off it. Do we keep paying a departed contractor a retainer for occasional availability, or buy a documented handover instead. Do we accept the six-month cost of staying on the current data model, or start the change now while the volume is still small. The fractional CTO's job in that moment is to write the options down with numbers attached and name a recommendation, then let the founder own the call. That split of authority is worth agreeing in writing early rather than discovering under pressure.

What we deliberately did not do in the first 90 days

No rewrite. No re-platform. No framework migration. No new hires. No architecture manifesto. Across three engagements, none of the first 90 days included a decision that could not be reversed within a week, and that constraint was chosen on purpose rather than arrived at by caution.

The argument against a first-quarter rewrite is not sentimental attachment to legacy code. It is that a rewrite proposed in month two is a proposal built on an incomplete map. You have not yet seen the seasonal traffic peak, the annual audit, the quarter-end reporting job that only runs four times a year, or the integration that a single large customer depends on. Systems that look redundant in February turn out to be load-bearing in September. Waiting one quarter costs very little and prevents the classic failure where new technical leadership burns its credibility on a migration nobody asked for.

Hiring is the other deferred decision. Founders frequently arrive with a drafted full-time CTO posting that is actually three roles taped together: an architect, a delivery manager, and a hands-on senior engineer. The honest recommendation after 90 days is often that the architecture and vendor judgement needs a few days a month of continuity, while the delivery load needs a full-time engineer, and those are not the same hire. That recommendation is only credible with the system map and risk register behind it.

How to run this yourself, and what a good 90-day report looks like

Run the same sequence with your existing team: two weeks read-only access inventory, four weeks of written artifacts, six weeks of one shipped change plus one escalated decision. At day 90 you should be able to hand someone a folder containing four documents and a changelog, with every claim traceable to something in the access inventory.

A good report is specific enough to be uncomfortable. It names the account still registered to a departed contractor. It names the monthly figure the unowned billing line represents. It says which single person can currently deploy to production. Generic findings like 'improve documentation' and 'increase test coverage' are a sign the audit never got past the surface, because those statements are true of every codebase ever written and therefore tell the founder nothing about their own.

This is the mode we work in as an embedded technical layer for founders without an in-house CTO, and the first quarter looks close to identical whether the product is a regulated diagnostics platform or a community fitness app. The domain changes what goes in the risk register. It does not change the order of operations.

If you want the decision-authority split written down before the first escalation lands, we published the escalation ladder we use with non-technical founders.