A good fractional CTO spends the first 90 days doing three things. Working out what you actually have, stopping whatever is on fire, and setting a direction the business can hold to once the noise dies down. By day 90 you should have a clear picture of your technology, a short list of fixes already underway, and a plan the board understands. Here is how that tends to play out, week by week, and what you should expect to see at each stage.
Before day one
The best first month starts before the contract is signed. A short conversation with the founder about what is keeping them up at night, a look at whatever documentation exists, and a request list. Access to the code, the systems, the suppliers, the numbers and the people. The faster an incoming CTO can see how things really work, the sooner the useful decisions start, and a founder who prepares the access in advance saves a fortnight.
I also ask one question before starting. What does the business need to be true in 12 months that is not true now. The answer shapes everything that follows, because the job is to get the technology to serve that, and nothing else.
Weeks 1 to 4, work out what you have
The first month is listening and looking. I read the code at a high level, sit with the team, talk to the people who sell and support the product, and look at where the money and the time actually go. I want to know three things. What is holding the business back today, what will break if you grow, and who on the team is carrying more than their title suggests.
In practice that means a dozen conversations, a few days reading, and a lot of quiet observation. How does a change get from idea to production. Who decides. What happens when something breaks at 5pm on a Friday. What do the invoices from the cloud provider and the agency actually cover. Where is the one person who, if they left, would take the whole system’s memory with them.
Most founders are surprised by what surfaces here. The problem they hired me for is rarely the biggest one. They call about slow delivery and the real issue is that nobody has ever tested a backup. They call about a security questionnaire and the real issue is that the agency owns the code. The first month is where those get found.
What you should see by the end of it is a short written picture. What you have, what is working, what is fragile, and the three or four things that matter most, in order.
Weeks 5 to 8, stop the bleeding and set priorities
By the second month the pattern is clear enough to act. There is usually something urgent, a security gap, a release process that keeps failing, a supplier who is not delivering, a key person about to burn out. That gets dealt with first, because nothing else matters if the lights go out.
A concrete example. One engineering team I took over had a release process that broke roughly one time in four, and each failure cost a day of firefighting and a nervous customer. Fixing it was not glamorous, a proper test step, a review before release, a rollback that actually worked. It took three weeks. Delivery became boring, which is the goal, and the team got a fifth of its time back.
Alongside the urgent work, this is where priorities get set. Not a wish list, a ranked set of decisions with a reason attached to each. What we do now, what waits, and what we deliberately choose not to do. Saying no clearly is half the job. Founders are often relieved to have someone else say it, because the no has usually been obvious for a while.
What you should see by the end of month two is the urgent risks handled or dated, a ranked list of priorities the whole leadership team has agreed, and a team that knows what it is working on and why.
Weeks 9 to 12, set the plan and the rhythm
The last month turns the picture into something durable. A technology roadmap tied to what the business is trying to achieve, a sensible way of reporting progress to the board, and a cadence the team can keep once I am less hands-on. If a hire is needed, this is where the brief gets written. If a delivery partner is needed, this is where it gets lined up.
The roadmap is deliberately short. A page, not a deck. What we are building this quarter and next, what we are fixing, what we are retiring, and the two or three bets that depend on the business plan being right. Each line has an owner and a reason. A roadmap nobody can hold in their head is a roadmap nobody follows.
The reporting rhythm matters as much as the plan. A monthly page for the board, a weekly check-in with the founder, and a visible board for the team. Boring, consistent, honest. The aim is that the business runs better whether I am in the room or not.
What good looks like at day 90
You can answer an investor or a bank’s technical questions without panic. The team knows what it is building and why. The worst of the risk is handled or has a dated plan against it. The spend is understood. And you have honest reporting, so the next 90 days are managed rather than guessed.
You should also know, by now, whether the fractional arrangement is the right one. Some businesses need more days for a while. Some need fewer. Some discover they need a full-time hire sooner than they thought, and the fractional CTO should say so and help write the brief.
What it will not do
Ninety days does not rebuild a platform or fix years of neglect. It gives you clarity, control and momentum. The heavy delivery that follows is a separate decision, and a fractional CTO should tell you plainly what that will take in time and money rather than pretend it comes for free.
It also will not work without the founder’s time. A day a week from the CTO needs a couple of hours a week from the founder, for decisions, context and the occasional hard conversation. A founder who delegates entirely and disappears gets a plan nobody owns.
The common mistakes
Hiring for the symptom. If the brief is ‘make delivery faster’ and the real problem is unclear priorities, you will get faster delivery of the wrong things. A good fractional CTO reframes the brief in month one, and a good founder lets them.
Skipping the assessment. Founders under pressure want action in week one. Action before understanding is how expensive mistakes get made faster.
Treating it as a contractor relationship. A fractional CTO is a member of the leadership team for the days they are there. Keep them out of the leadership conversations and you get a technician, not a leader.
This matters more in a soft hiring market. UK vacancies fell to 712,000 in the three months to June 2026, down on the year, so more businesses are reaching for senior help without committing to a full-time salary. The first 90 days are how you find out whether that help is working.
Frequently asked questions
How many days a week does a fractional CTO work in the first 90 days?
Usually one to two days a week. The first few weeks sometimes run a little heavier while the assessment happens, then it settles into a steady rhythm.
Will a fractional CTO write code?
Some do, most lead. In the first 90 days the value is in judgement, direction and unblocking the team, rather than in adding another pair of hands to the backlog.
What should we have ready on day one?
Access to the team, the code, the key suppliers and the numbers. The faster an incoming CTO can see how things really work, the sooner the useful decisions start.
What if the fractional CTO finds something serious?
They tell you immediately, with an honest view of the risk and the cost of fixing it. Finding the serious things early is the point of the first month, and it is far cheaper than a customer or an investor finding them later.
How involved does the founder need to be?
A couple of hours a week for decisions and context. The arrangement fails when the founder delegates entirely, because the plan ends up with no owner inside the business.
What happens after the first 90 days?
Either a lighter ongoing role keeping the plan on track, or a heavier delivery phase if the roadmap calls for it. Our forward deployed engineering work covers the delivery side when that is what the plan needs, and a technology review is often how the first month’s assessment is run.