How a fractional CTO engagement works, from first call to handover

A fractional CTO engagement usually moves through the same stages: a short fit call, a paid discovery or audit, a scoped proposal, then ongoing work on a monthly retainer or a set number of days a week, with weekly demos and monthly reviews. It ends with a planned handover, often to a full-time hire or an in-house lead.

The names and lengths vary from one fractional CTO to the next. The bones shouldn't. If one of the stages below is missing from a proposal you've received, ask why.

The stages of a fractional CTO engagement at a glance

The lengths are typical ranges, not rules. A rescue project compresses the early stages; a large existing team stretches onboarding.

As one concrete version, here is my own fractional CTO service, in four steps:

1. A WhatsApp chat. You describe the product, and I tell you honestly whether I'm the right fit.
2. A two-week discovery sprint that ends with a roadmap, an architecture and a real estimate.
3. Building in weekly sprints, with working software every week and a demo every Friday.
4. Launch, then I stay on as CTO on a monthly retainer for as long as the company needs one.

Before you commit: the fit call and discovery

The fit call

The first conversation is a screen in both directions. Bring a short description of the product, who it's for, what exists today (code, designs, a vendor, or nothing), a rough budget and any hard deadline.

A good fractional CTO listens more than they talk, and says so plainly if you need someone else: a specialist, an agency, a full-time hire, or more customer validation before anyone writes code. To prepare your side of the conversation, here are the questions worth asking before you sign.

Discovery or audit

Next comes a short, paid, fixed-scope piece of work. It's the best interview you can run: you see how the person thinks, writes and communicates on your actual problem, and you keep the output even if you part ways.

• For a new product, discovery maps the core user journeys, decides what the first version must include, makes the build-or-buy calls, and produces an architecture, a phased roadmap and an estimate you can plan around.
• For an existing product, an audit reviews the code, architecture, infrastructure, security, costs and the team or vendor setup, and ends with a prioritized list of risks and fixes.

Either way, the output should be written down. A discovery that ends with "let's just get started" and no documents hasn't done its job.

Which engagement model should you choose?

The proposal that follows discovery sets out how you'll work together. Most fall into one of four shapes, or a mix of them.

Mixes are common, such as a retainer with a set number of days included and a separate fixed fee for a one-off due diligence project. Whatever the shape, the proposal should spell out the scope (what the CTO owns and what they don't), availability and response times, the meeting cadence, how hours or scope can change, and the notice period.

For what each model tends to cost, see typical fractional CTO pricing. For the clauses that protect you, see what belongs in a fractional CTO contract.

The first weeks: access, tools and ground rules

Onboarding is mostly about access and habits. Get these right and everything after gets easier.

• Code repositories, cloud accounts, domain and DNS, app store accounts and analytics are in the company's name, with the CTO added as a user.
• Passwords and secrets live in a password manager the company owns, never in chat messages.
• One chat channel for quick questions, one issue tracker for work, one shared folder or wiki for documents.
• Agreed response times for normal questions and for emergencies.
• A decision log, started on day one.
• The weekly demo and the monthly review are in everyone's calendar.

Founders skip the first item most often, and it hurts most later. If a developer, an agency or even your CTO holds your accounts in their own name, you don't fully control your product, which is why code and account ownership deserves attention on day one. For what the first quarter should deliver, stage by stage, see a realistic first 90 days with a fractional CTO.

What the weekly and monthly rhythm looks like

A part-time CTO is only accountable if progress is visible on a schedule. This is the cadence I'd expect in any engagement.

Every week: a demo and a written update

Working software, shown live or recorded. Not slides, and not a list of tickets. Then a short written update under five headings:

1. What shipped.
2. What's planned next.
3. What's blocked, and who can unblock it.
4. Decisions needed from you, each with a recommendation.
5. Risks you should know about.

Every month: direction and spend

Step back once a month: progress against the roadmap, tech spend (hosting, tools, vendors and the CTO's own hours), open risks, hiring needs, and whether the priorities still match the business. It's also the right moment to raise anything that isn't working in the engagement itself.

Every quarter: reset the plan

Every three months or so, revisit the roadmap and the shape of the engagement. Is the CTO spending time where it matters most? Should hours rise for a launch, or fall because a team is now in place?

Across time zones, nearly all of this works asynchronously, as long as the written updates are good and there are a few hours of overlap for live calls.

Can you scale a fractional CTO's hours up or down?

You should be able to, since flexibility is half the point of the model. Common reasons to scale up are a build or launch phase, a fundraise or due diligence, a security incident or a change of vendor. Common reasons to scale down are a stable live product, an in-house lead now running the team, or a quieter phase of the roadmap.

Agree on the mechanics in the contract before you need them: how much notice each side gives for a change, whether unused hours roll over, and how a short spike in hours is billed. A CTO who lets hours quietly drift upward, or resists scaling down when you no longer need them, is showing you a warning sign.

How does a fractional CTO engagement end?

Every engagement ends eventually, and good ones end on purpose. The usual reasons are healthy: you've hired a full-time CTO, an internal lead is ready to take over, or the company no longer needs CTO-level time. Sometimes it simply isn't working, and a clean exit beats a slow fade.

Either way, a proper handover includes:

• Admin rights to every account confirmed in the company's hands, and the CTO's access removed on an agreed date.
• Current architecture notes, the decision log and a runbook for deployments and incidents.
• The roadmap, open risks and known technical debt, written down.
• Vendor contracts, renewal dates and contacts.
• Recorded walkthroughs of the codebase and the infrastructure.
• An overlap period with the successor, and an agreed way to ask questions afterward.

When the successor is a full-time CTO, the fractional CTO often helps write the role, interviews candidates and onboards the person hired. That process is covered in planning the handover to a full-time CTO.

Where to start

Treat the first call as a two-way screen, pay for a short discovery before committing to months, and agree on the rhythm and the exit before work starts. If the weekly demo and written update happen reliably, almost anything else can be fixed at a monthly review. If they don't, nothing else will make up for it.