What a fractional architect does in the first 90 days

In the first 90 days, a fractional architect learns the system, writes down what they find, and then settles into a rhythm your team can rely on. Weeks one and two go on reading the code, the infrastructure and the backlog, and talking to everyone. By the end of the first month you have written findings and a short list of agreed priorities. Months two and three are the working pattern: decisions recorded as they’re made, design and code reviews on the risky changes, a seat in planning, and hands-on work on the piece that most needs a senior pair of hands. At day 90 you decide, with evidence, whether to carry on.

That is how I run the first three months of a fractional engagement. This article goes through it in more detail: who it suits, what each stage produces, what changes for your team, and when it isn’t worth paying for.

Who a fractional architect is for

A fractional architect, or fractional CTO, is a senior technical lead who works with you part time, typically a few days a month, rather than as a full-time hire. My engagements run two to eight days a month, with a three-month minimum and then month to month, and I’m available on Slack or Teams between those days.

It suits a particular kind of company. Usually a founder-led SaaS business with a small development team, past its first paying customers and not yet big enough to need, or afford, a full-time CTO. The developers are capable. What’s missing is someone senior who owns the whole system: how it fits together, where it’s heading and what will break first.

The signs are familiar. Architecture gets decided ticket by ticket. A founder is still acting as CTO in the evenings. The lead developer has left. Something risky is coming, such as a rebuild, a major integration or the first time the product moves money. Or investors and enterprise customers have started asking technical questions nobody can answer with confidence.

The term “fractional CTO” gets used for everything from a part-time engineering manager to an adviser who joins one call a month. The 90 days below describe the hands-on version: someone who reads the code, reviews the designs and still writes some of it.

Before day one

A good engagement starts before the first working day. On an intro call we talk through the product, the team and what needs covering, and I’ll say plainly if a fractional lead isn’t the right answer.

If it is, we agree three things up front:

• The days. How many a month and how they fall. A common pattern is a fixed day each week plus the team’s planning sessions. Predictable days let the team save up the questions that need a conversation.
• The between-days arrangement. Which channel, what kinds of question, and what response time is reasonable. Async availability is part of the job, but it works best with expectations set on both sides.
• Access. Read access to the repositories, the cloud accounts, the CI/CD pipeline, error tracking, the backlog and whatever documentation exists. Waiting a week for access is an easy way to lose most of a first month.

Weeks 1–2: learning the system and the people

The first two weeks are for listening and reading. I resist changing things in this period, apart from genuine emergencies such as an exposed secret or a backup that has never been restored. Advice given before I understand the system is advice I’ll have to take back.

The reading is concrete:

• The critical paths, end to end. Sign-up, billing, the main workflow customers pay for, and anything that moves money or sensitive data. I trace each one through the code and the infrastructure, and compare what the system actually does with what people believe it does.
• The infrastructure. Cloud account structure, access and permissions, how environments differ, what is defined as code and what was clicked together in a console, and where the cloud bill goes.
• How change gets to production. Branching, review, tests, the pipeline, how a release is rolled back, and how long all of that takes.
• History. Recent incidents, the bugs that keep coming back, the parts of the code people avoid touching.

The conversations matter as much as the code. I talk to the founders about where the business is going in the next year or two, to each developer about what slows them down, and to whoever handles support about what customers actually complain about. I ask everyone the same few questions:

• What would you fix first if you had a free month?
• What part of the system are you most nervous about changing?
• What decision was made that nobody remembers making?
• What do customers or investors ask that you can’t answer well?
• What would break first if usage doubled?

The answers rarely agree, and where they disagree is usually where the real problems are.

End of month one: written findings and priorities

The first deliverable is a document, not a slide deck. It’s short enough to read in one sitting, and written so that founders, developers and, if needed, a board or an investor can all follow it.

The structure I use:

# Findings and priorities: month one

## Summary (one page, no jargon)
What the system is, what's working, the three things that matter most.

## What's working
Strengths to protect while everything else changes.

## Risks, ranked by impact
Each with: what it is, what triggers it, what it would cost, what to do.

## Priorities for the next two months
Three to five, agreed with the founders and the team.

## Not now
Things worth doing that we are deliberately not doing yet, and why.

Two sections do more work than they appear to. What’s working stops a new senior person from treating everything as broken, which is how good teams lose confidence and good code gets rewritten for no reason. Not now is where the long list goes, so it stops competing with the short one.

The priorities aren’t mine alone. I walk the founders and the team through the findings, we argue about the ranking, and we agree the short list together. A priority list the team didn’t help shape tends to stay a document.

If the first month surfaces something that needs a deeper look, such as a data model that won’t survive the next stage of growth, it goes on the list as its own piece of work, with an estimate. Sometimes that is better handled as a focused architecture review than inside the monthly days.

Months 2–3: the working rhythm

Once the priorities are agreed, the engagement turns into a routine. The routine is the product: the team should know when I’m around, what I’ll look at and how to get a decision.

Decision records

Architectural decisions get written down as short decision records, one per decision, kept in the repository next to the code. Each is quick to write, and it answers “why did we do it this way?” a year later, when nobody remembers:

# 0007: Keep payment state in our own database, not only the gateway's

Status: accepted
Date: 2026-11-04

## Context
Payments are only recorded in the gateway dashboard. Support can't see
them, refunds are manual and reconciliation is done in a spreadsheet.

## Decision
Every payment gets a record in our database before the gateway is
called, keyed by a payment ID we generate.

## Consequences
One extra table and a reconciliation job. Retries become safe and
support can see payment history without gateway access.

The habit matters more than the template. Within a couple of months I want developers writing records themselves, with me reviewing them rather than authoring them.

Reviews where they count

I don’t review every pull request; that would make me a bottleneck on a few days a month. I review designs before significant work starts, and code for the changes that are hard to undo: data model migrations, anything that moves money, authentication and permissions, infrastructure changes. A rough rule the team can apply themselves: if getting it wrong would need a data fix or an incident report, it gets a senior review.

Planning with the business

I sit in on roadmap and sprint planning, turn business goals into technical options with honest trade-offs, and raise risks while there’s still time to plan around them. Often the most useful thing I say in planning is that a feature is much cheaper if it’s done in a different order, or much more expensive than it looks.

Hands-on work

On my days I usually take one risky piece myself and pair on it with a developer: a ledger change, a payment flow, the infrastructure as code for a new environment. It keeps my advice grounded in the actual code, and it transfers the knowledge to someone who’ll still be there next month. The trust accounting ledger and payment gateway articles describe the kind of work that usually ends up in this slot.

What a month can look like

For a team on four days a month, a typical month might look like this:

When	What
Week 1, day 1	Sprint planning, design reviews, a decision record or two
Week 2, day 2	Hands-on: pairing on the risky piece of work
Week 3, day 3	Code reviews of high-risk changes, founder check-in
Week 4, day 4	Retro, update the priorities, plan the next month
Between days	Questions and quick reviews on Slack or Teams

The pattern flexes. A release or an incident can pull days forward, and a quiet month can drop a day. That’s the point of agreeing a monthly number rather than a fixed calendar.

What changes for your team

Done well, the changes are mostly quiet ones:

• Decisions have an owner and a record. Developers stop relitigating old choices, and new starters can read why the system is the way it is.
• Risky changes get a second pair of eyes before they ship, not after the incident.
• Developers have someone to escalate to on technical calls that need a senior view, without it landing on a founder.
• Founders get answers. When an investor or an enterprise customer asks about security, scaling or data handling, there’s someone who can answer, or who can write the answer down.

There are costs too. There’s a little more process: decision records, design reviews, a written priority list. And there’s someone senior asking awkward questions about the plan. Both are the point, but they’re worth knowing about before you start.

How to judge it at day 90

The three-month minimum exists because the first month is mostly learning; you can’t judge an engagement on it. By day 90 there should be evidence either way. The questions I’d ask in the review:

• Did the agreed priorities move? Not finished, necessarily, but moved.
• Are decisions being written down, and are developers writing some of them?
• Did anything risky ship with less drama than it would have before?
• Do the founders spend less of their own time on technical questions?
• Is the team asking for more of this, or putting up with it?

If the answers are mostly yes, it continues month to month, with the number of days adjusted to the work ahead. If they’re mostly no, it’s better to stop and say why than to drift.

When a fractional architect isn’t worth it

It’s not the right answer for every team, and saying so early saves everyone money:

• You have no developers yet. A part-time architect with nobody to direct produces documents. You need people building, which might be a design and build engagement or your first hires, with fractional leadership later.
• You need someone full time. A large team, a product in daily crisis or a major rebuild running at full speed needs leadership every day, not a few days a month.
• You have one question. If what you need is an outside view before a single decision, such as a rebuild, a raise or an acquisition, a fixed-scope architecture review answers it faster and for less.
• You won’t act on the advice. If the roadmap is fixed and there’s no room to change how the team works, a fractional architect becomes an expensive observer.

How it ends: handover

A fractional engagement should be built to end. The usual endings are that the team grows into it, or the company is ready for a full-time CTO or lead engineer.

In the second case I help write the role, interview candidates and hand over properly. The handover is easy if the engagement has been run as above, because most of what the new person needs already exists: the decision records, the findings and their updates, the risk list, and an architecture overview kept current along the way. What’s left is a few weeks of overlap, so the new lead hears the reasoning behind the decisions, not just the decisions.

After the three-month minimum, either side can end it with a month’s notice. That keeps it honest: it continues because it’s useful, not because a contract says so.

If you’re weighing up a fractional CTO or architect for your team, my fractional CTO and tech lead page sets out how I work and what to expect.