Fractional CTO 30/60/90-Day Plan for Austrian Startups

You have hired a fractional CTO. What should the first 90 days actually produce? Days 0 to 30 are assess and stabilize: a listening tour, shadowing the real work, a risk triage, and only low-risk quick wins, ending in a written state-of-engineering assessment. Days 31 to 60 are plan and lay foundations: a technical roadmap tied to business goals, a hiring plan, a delivery cadence, basic engineering metrics, and fixing the top one or two risks. Days 61 to 90 are execute and get handover-ready: ship something through the new cadence, report to the board in risk and investment terms, and set the org up to run without daily CTO presence. The value of a fractional CTO is not being the smartest technical person in the room. It is a set of artifacts and a running system that survive their departure.

This is the execution plan. For whether to hire one at all and what they cost, see when to hire a fractional CTO in Austria and the day-rate breakdown. This post answers the next question: now that one is in the building, what happens.

The one principle that shapes the 90 days

The biggest mistake a new technical leader can make is disrupting the current systems of execution before they have a working alternative. A startup that ships, even messily, is more valuable than one frozen mid-reorg. So the plan front-loads understanding and back-loads change. The first month is mostly listening; real change starts only once the leader actually understands how the place works.

Days 0 to 30: assess and stabilize

The mode here is sponge, not bulldozer. Meet everyone one to one (in a team under 30 people, literally everyone), and ask two questions: what would you change, and what is working so well that we must not break it. Shadow the real work: sit with support tickets, watch an incident, and ship one trivial change yourself to feel the deployment pipeline. In parallel, run a risk triage that becomes the first artifact: security, single points of failure, key-person and bus-factor risk, infrastructure cost, and delivery bottlenecks. Take only quick wins that are low-risk and reversible, the kind that earn trust without betting the company.

What a good fractional CTO deliberately does not do in month one: no rewrites, no reorganisations, no process overhauls, and no firing, with the single exception of a genuine security or safety threat. Anyone proposing a from-scratch rewrite in week two is showing you a red flag, not leadership.

Days 31 to 60: plan and lay foundations

Now change starts, but in bounded experiments, not a big bang. Run at most one or two time-boxed changes so the team is not overwhelmed. Produce the prioritized technical roadmap that ties engineering work to the runway and the product goals. If hiring is needed, write a focused plan for at most a few key roles, because recruiting has fixed overhead per role and ten open reqs is its own failure. Establish the delivery cadence: sprints, standups, code review, and a clear definition of done. Stand up basic engineering metrics (the four DORA keys are the standard starting point). And fix the top one or two risks from the register, capturing the architecture and vendor decisions as decision records as you go.

Days 61 to 90: execute and get handover-ready

Ship something real through the new cadence, so the change is proven, not just announced. Establish a recurring report to the founders or board that speaks in the two currencies a board actually thinks in, risk and investment, not story points. Finalise the decision records and the runbook. And do the thing that defines a fractional engagement: set the organisation up to run without the CTO in the room every day. A useful self-test at day 90 is whether you can say what is distinct about each person on the team; if you cannot, you have not had the right conversations. Finally, write down the success metrics and the trigger that will tell you it is time to hire a full-time CTO.

The artifacts a good fractional CTO leaves behind

This is the difference between a real engagement and an expensive Slack presence. Demand these.

A fractional CTO who leaves you with a working team and these documents has done the job. One who leaves you with vibes and a chat history has not.

How to measure them, and the anti-metrics

Measure delivery predictability with the four DORA keys (deployment frequency, lead time for changes, change failure rate, and time to restore service), the count of risks closed from the register, team velocity and morale as trends rather than absolutes, roles hired against the plan, and the most underrated one: how much founder time got freed because the founder is no longer the escalation path for every technical decision.

Do not measure lines of code. It rewards volume over value, and deleting code is often the win. The Lisa engineer who reported negative 2,000 lines of code on a productivity form, having made the software faster and smaller, had it exactly right. And be wary of a CTO whose plan is a from-scratch rewrite; rewriting working software from zero is one of the classic strategic mistakes, because it is harder to read code than to write it, and the old code carries years of fixed bugs.

"A fractional CTO is hired to make themselves unnecessary on a schedule. The deliverable is not their presence in meetings. It is a team that ships without them and the handful of documents that let the next person pick up where they left off."

When to replace a fractional CTO with a full-time hire

The trigger is when engineering management becomes a full-time job. Practically, that is around the point where one person can no longer hold the team in a healthy span of control, roughly the eight-or-more-engineers mark, and where someone is spending more than half the week on management rather than building. Combined with being past product-market fit and needing sustained daily execution, that is the signal to bring the role in-house. We cover the cost and timing in when to hire a fractional CTO in Austria, so the point here is the handover, not the math.

Run the transition as a slow roll, not a clean break. The fractional CTO writes the job description and vets candidates for their own replacement, runs structured knowledge transfer, and hands over people knowledge alongside the systems. This is exactly where the artifacts pay off: the decision records, the roadmap, and the runbook are the handover package. The incoming full-time CTO owns decisions from day one, and the fractional steps back to advisory or out.

The Austrian angle

The engagement is almost always a business-to-business retainer, not employment, structured as a freier Dienstvertrag or ordinary self-employed contract for ongoing availability, or a Werkvertrag when there is a single concrete deliverable. That keeps it free of wage-tax and employment obligations, but it has to be structured to avoid bogus self-employment (Scheinselbstständigkeit), so the CTO genuinely sets their own time and means. The senior engineering market is tight, especially outside Vienna, where filling a senior role can take many months, which is part of why a fractional leader who can also hire well is valuable. And a good one knows the funding map: aws programs fund company building and seed or growth financing, while FFG funds genuine research and development, so the roadmap and its documentation should be structured so that R and D work maps cleanly to FFG and company building maps to aws. That is a concrete, money-on-the-table reason the documentation discipline matters here.

Fractional, interim, full-time, or co-founder?

For the execution phase, the distinction that matters is simple: interim is full-time but temporary, fractional is part-time but ongoing.

For an early-stage startup at or just before product-market fit, the fractional CTO builds the runnable system; an interim plugs a hole; and full-time or a co-founder answer a different question about permanence and ownership.