In this piece
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.
We reviewed the external references and Austrian contracting and funding guidance on 2 September 2026. The 30/60/90 sequence is an operating template, not a statutory rule or a promise that every company should change on the same day.
Want a fractional CTO who works to a plan like this?
Book Free ConsultationThe 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 only as many time-boxed changes as the team can absorb. Produce the prioritized technical roadmap that ties engineering work to runway and product goals. If hiring is needed, sequence the few roles that remove the most important constraint. Establish a delivery cadence that fits the team, with review and a clear definition of done. For software delivery, DORA now documents five metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. Use them as trends for one service, not as individual targets. Fix the top risks from the register and capture material architecture and vendor choices as decision records.
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.
| Artifact | What it is and why you want it |
|---|---|
| State-of-engineering assessment | A written audit of tech, team, delivery, and risk after the listening tour. Your honest starting baseline. |
| Risk register | A named, owned list of risks with likelihood, impact, and mitigation. Makes key-person risk visible instead of implicit. |
| Technical roadmap | Engineering work sequenced against business goals and runway, so tech decisions trace back to outcomes. |
| Architecture decision records | Short documents capturing the context, the decision, and its consequences, so the next team knows why, not just what. |
| Hiring plan | A few prioritized roles with sequencing and draft descriptions, not a scattershot of open reqs. |
| Delivery process doc | Sprints, standups, code review, and a definition of done, written down so the cadence outlives the CTO. |
| Board tech report | A recurring update in risk and investment terms that founders can take to investors. |
| Runbook | Step-by-step operational and incident procedures. A documented playbook restores service far faster than improvising. |
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 with DORA's five current metrics at service level, the risks mitigated from the register, hiring progress against the plan, a lightweight team-health signal, and founder time freed because every technical decision no longer escalates to the founder. Pair speed with stability and outcomes so no single metric becomes the goal.
Do not measure lines of code. It rewards volume rather than outcomes and penalizes simplification. Treat a proposed rewrite as an investment case: require evidence that incremental change cannot meet the goal, list migration and rollback paths, and compare the full opportunity cost. The same standard applies to every large architecture change.

"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 sustained need for daily executive ownership, not a universal engineer count. Consider a full-time hire when people leadership, hiring, delivery risk, stakeholder work, and technical decisions consistently exceed the agreed fractional capacity, and when the company can fund and retain the role. Team topology, manager capability, product risk, and growth rate matter more than a fixed span-of-control rule. We cover the cost and timing in when to hire a fractional CTO in Austria, so the point here is the handover, not a headcount threshold.
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
In Austria, the contract label does not decide the legal classification. The Business Service Portal says the actual economic relationship is decisive. A free service contract normally covers continuing, largely personal work without personal dependence and is paid by time; it can still create social-insurance and employer-levy duties. A Werkvertrag instead owes a defined result, ends when that result is delivered, and places planning, equipment, and economic risk with the contractor. Have Austrian counsel or payroll specialists classify the real working arrangement rather than relying on the title.
Funding also does not split neatly into "company building equals aws" and "development equals FFG." The aws Preseed Deep Tech program can fund proof-of-concept work and eligible external services for qualifying deep-tech startups. The FFG Basisprogramm supports defined R&D projects with technological novelty, technical risk, and commercialization potential, not general startup financing. Match the roadmap, costs, and start date to the current program guide before committing work.
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.
| Fractional CTO | Interim CTO | Full-time CTO | Technical co-founder | |
|---|---|---|---|---|
| Commitment | Part-time, ongoing | Full-time, fixed term | Permanent, full-time | Indefinite, full-time plus |
| Mostly paid in | Cash retainer, small long-term equity | Cash | Salary plus exec grant | Equity |
| Best execution-phase fit | Build the system and the artifacts, prep the handover | Crisis or gap cover (a departure, a turnaround) | Sustained daily execution post-PMF | Owns the tech from day zero, pre-product |
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.
Our fractional CTO service runs the 90 days described above on a retainer that cancels weekly, with two founders on the engagement rather than one contractor. If the missing person is closer to a partner than to a hire, the fractional co-founder shape answers the ownership question instead. Fractional versus interim CTO sets the two side by side, and Polity shows the delivery system that survives after the engagement ends.
Frequently Asked Questions
What does a fractional CTO do in the first 90 days?
What artifacts should a fractional CTO deliver?
What should a fractional CTO NOT do in month one?
How do I measure a fractional CTO?
Why are lines of code a bad metric?
When do I replace a fractional CTO with a full-time hire?
How do I run the handover cleanly?
Fractional CTO versus interim CTO?
How is a fractional CTO contracted in Austria?
Can a fractional CTO help with aws or FFG funding?
Final thoughts
A fractional CTO's first 90 days are not about being the cleverest engineer in the room. They are about understanding the system before changing it, fixing the risks that actually threaten the company, and leaving behind a team that ships and a set of documents that outlast the engagement.
Assess and stabilize, then plan and lay foundations, then execute and prepare the handover. Judge the result by delivery predictability, risks closed, and founder time freed, never by lines of code. Done well, the engagement ends with the org running without daily CTO presence and a clean trigger for when to hire full-time, which is exactly the point.