What a fractional CTO does in the first 90 days

In the first 90 days a fractional CTO listens, takes stock of every system and vendor, fixes the biggest risks, and leaves the business with a roadmap, a budget view and a working rhythm for technical decisions. The first month is for understanding, the second for deciding, and the third for putting new habits in place.

What does a fractional CTO actually do?

A fractional CTO is a part-time technology leader who sits on your side of the table. They are not a developer you add to the team, and not an agency that sells you a project. Their job is judgement: what to build, what to buy, who should do it, how much it should cost and whether the result is any good.

They tend to work in a steady rhythm: a weekly session with the founder or leadership, time with the developers or vendors, and written output you can act on. Our fractional leadership model is monthly, with a defined scope and no hours counting.

What happens in days 1 to 30?

The first month is for listening and mapping. A good start looks like this:

1. Talk to the people who use and build the systems: founders, sales, operations, support, developers, vendors. The aim is to understand how the business makes money and where technology gets in the way.
2. Take an inventory: every product, server, domain, SaaS tool, repository, third-party service and integration. Who owns each one, who has access, what it costs.
3. Check access and ownership: are the domain, cloud accounts and code repositories in the company's name? Does one person hold every password? This is often the most urgent finding.
4. Review security and data basics: MFA, backups, secrets in code, personal data handling. Our guides on the first DPDP steps and backups cover typical gaps.
5. Read the money: cloud bills, licences, vendor invoices, contractor costs. Find out what the business spends and on what.
6. Sample the work: skim the code, deployment process and documentation. A few hours is enough to judge how healthy it is.

The month ends with a written readout: what is working, what is risky and what is unknown.

What happens in days 31 to 60?

The second month is for decisions.

• Rank the risks and opportunities: not everything gets fixed. A short list: the three things that could hurt the business soonest and the three that could help it most.
• Make the quick fixes: move accounts to company ownership, switch on MFA, set up backups, cancel unused tools, close the worst security gaps.
• Judge the vendors: for each agency, freelancer or platform, ask whether they deliver, whether the price is fair and whether the relationship should continue. A second opinion on a quote is a common tool here.
• Draft the technology roadmap: tie it to business goals for the next 6 to 12 months, covering what to build, what to improve, what to retire.
• Sketch the team plan: do you need a full-time engineer, a product manager, a designer? Which roles can wait?

What happens in days 61 to 90?

The third month is for habits.

• Set a cadence: a short weekly review of delivery, a monthly review of cost and risk, a quarterly roadmap check. Put these in the calendar.
• Introduce light process: how work is requested, prioritised, reviewed and released. Enough structure to avoid chaos, not enough to slow people down.
• Write things down: architecture notes, decision records, runbooks for the top incidents. Knowledge should not live in one head.
• Start hiring or vendor changes: write the job descriptions, interview candidates, run the vendor selection or hand the brief to new vendors. See how to write a brief vendors can quote on.
• Report to leadership: a plain one-page summary of progress, spend and risk each month.

What should you have at the end of 90 days?

A reasonable set of outputs:

• A system and vendor inventory with owners and costs.
• A risk register with the top items and their status.
• A technology roadmap tied to business goals.
• A budget view of what technology costs and why.
• A vendor assessment with recommendations.
• A hiring plan.
• A working cadence, and notes that someone else could pick up.

If you do not have these, ask why.

When is a fractional CTO the wrong choice?

Be honest about fit.

• If you need hands-on building every day, hire developers or a dedicated team instead.
• If the business is large and technology is the product, you probably need a full-time CTO.
• If nobody inside the business can act on the advice, the engagement will stall. Someone must own the follow-through.
• If the person advising you also profits from the work they recommend, be careful. Ask how recommendations are kept independent. Our own rule is simple: if we are not the right team for it, we say so.

What are the trade-offs?

Part-time means the person is not there when something breaks at midnight unless the agreement says so. Agree on how urgent issues are handled.

Context takes time. The first month is spent learning, not shipping.

A fractional CTO costs less than a full-time hire but is not free, and the value depends on decisions being made. A report left unread is wasted.

Where does TechSum fit?

We offer fractional CTO and fractional AI officer roles as monthly engagements, with technology strategy, architecture review and vendor management inside the same scope. Read more on the fractional CTO page and the Tech Consultancy pillar. A lighter first step is a Tech Second Opinion on one quote or build, and you can run the free health check on your website.