The managing director of a 20-person company comes out of an investor meeting with a list of questions she cannot answer. Will the architecture cope with a second market? What does the platform cost to run, and why has the cloud bill gone up by half in six months? Is the software house that has been building the product for two years doing a good job, or just sending invoices? Who is accountable for customer data security? She knows the market and the customers, but she is not an engineer. The closest thing to a technical leader is a senior developer who writes excellent code but has never built a budget or negotiated a vendor contract.
The first reflex is “we need a CTO”. The second, after a look at the market and a conversation with a recruiter, is doubt: a full-time senior technology leader is one of the most expensive hires a company of that size can make, the search takes months, and half of that person’s week would be hard to fill at this stage. A third option keeps coming up in conversations: a fractional CTO.
This article is for the CEO or founder considering that route. We explain what a fractional CTO actually does and what they will not do, how to price their time, which commercial models make sense, what to write into the contract, how to tell when part-time has stopped being enough, and where services such as an independent code audit fit in. To be clear from the start: ARDURA Consulting does not sell a “fractional CTO” package. We write about it because we regularly talk to companies facing this decision, and some of them need something different from what they think.
What exactly is a fractional CTO?
A fractional CTO is an experienced technology leader who acts as your chief technology officer for an agreed number of days a month. They are not a one-project consultant and not a developer moonlighting after hours. They carry the same responsibilities as a full-time CTO at a smaller scale: technical direction, the quality of architecture decisions, the relationship with the team or vendor, and making sure the board understands what it is spending money on.
The most common commitment is one to two days a week, sometimes half-time. Below one day a week it is hard to speak of a CTO role at all, because the person cannot keep up with what is happening and turns into an on-call adviser. Above three days a week the cost gap to a full-time hire narrows, and the company loses what is most valuable in the fractional model: access to someone who sees several companies at once and is not consumed by daily firefighting.
Three related roles are often confused. A fractional CTO stays for the longer term, usually a year or more, and takes responsibility for decisions. An interim CTO works full-time for a few months, typically during a crisis or while a permanent successor is recruited. A technology adviser answers questions but does not make decisions and is not accountable for their consequences. If the contract does not name a single decision the person owns, you are buying advice, not a CTO, and it is worth saying so plainly, because price and expectations depend on it.
One more definitional point: a fractional CTO rarely sits on your payroll. They are usually an independent contractor or someone provided by a consultancy. That changes the commercial and legal set-up, covered below, but not the role itself.
What does a fractional CTO do day to day?
A well-designed engagement has a short list of responsibilities you can check after a quarter. It usually covers six areas.
Technical direction and architecture. The CTO makes or approves the key calls: monolith or services, which cloud, build or buy, when to pay down technical debt. They do not draw every diagram, but they make sure decisions are reasoned and written down. A practical tool is an architecture decision record (ADR) in the format Michael Nygard described in 2011: context, decision, status, consequences. A year later anyone can see why the system looks the way it does, even if the CTO has moved on. If you need the vocabulary, our glossary entry on software architecture is a good starting point.
Oversight of the team or vendor. If a software house builds your product, the CTO sits on your side of the table: they read estimates, ask hard questions about quality and check that delivery matches the contract. If you have your own team, the CTO sets ways of working, reviews key changes and coaches team leads, without managing every developer personally.
Technology budget. Cloud, licences, tools, people and vendors in one place, with a plan for the year and an explanation of what changes if the company doubles. This is often the first document a fractional CTO produces, and the first one the board actually needs.
Hiring and team structure. The CTO writes technical role profiles, interviews candidates for key positions and decides which skills to hire permanently and which to bring in from outside. Many companies discover at this point that they do not need five more developers but one experienced architect and a better delivery process.
Security and compliance. Not configuring firewalls personally, but owning the risk list: who has production access, where the backups are and whether anyone has ever restored one, what personal data the system processes under GDPR, when the last security test took place.
Investor and customer conversations. An investor before a round, an enterprise customer before signing, a customer’s security assessor: they all want to speak to whoever is accountable for technology. The fractional CTO is that person, prepares the materials and answers the technical questions.
What is missing from that list? Writing code. That is deliberate, and we return to it below.
When is a fractional CTO enough, and when do you need a full-time one?
This is the central question, and the answer depends less on company size than on how often blocking technical decisions arise.
Part-time usually works when three conditions hold. First, the technical team is small, up to a dozen or so people, or an external vendor builds the product. Second, the company has one main product and a stable direction rather than five experiments at once. Third, someone already runs the team’s day-to-day work, such as a tech lead or the vendor’s project manager, so the CTO does not need to be available every hour of the day.
Full-time becomes necessary when any of these stops holding. The team grows past a dozen or so people and needs daily leadership rather than weekly. Technology becomes the main competitive advantage: the company builds its own models, a platform for other businesses or a product sold through an API. Or technical decisions come up daily, and every day spent waiting for the CTO costs the team real time.
There is also a signal that is easy to miss: the fractional CTO regularly works more than the contract says. If two days a week become four for three months in a row, that is not proof of commitment; it is proof that the company needs a full-time leader. The best fractional CTOs say so themselves and help recruit their successor.
A caveat from the other direction. Some companies hire a fractional CTO because “we need somebody technical anyway”, while their real problem is narrower: they do not know whether the vendor is doing a good job, or they do not know what is in the code they are buying. That question has a bounded answer and does not need a twelve-month contract. We cover it in its own section below.
How many days a month should you plan for?
The commitment should follow from the task list, not from whatever budget “should be enough”.
In a company with an external vendor and one product, the recurring duties are usually a weekly vendor meeting and progress review, a monthly cost and risk review, quarterly planning and review of major architecture changes. That fits into four to six days a month, roughly one day a week, plus a few hours of availability for urgent questions.
In a company with its own team of five to fifteen people, add hiring, developing leads, setting up the delivery process and more frequent architecture decisions. The realistic commitment is closer to eight to ten days a month, or two days a week.
The first three months are an exception. The CTO has to learn the system, the people, the contracts and the costs, and often fix what has been neglected. It is sensible to plan a heavier commitment for that period and drop to the target level from month four. If a candidate proposes the same commitment from day one, ask them when they intend to read the code and the contracts.
Finally, keep a reserve. A production incident, an investor question due tomorrow, a key person resigning: these things happen. The contract should state how many extra hours per month are available and at what rate, rather than pretend there will be none.
How much does a fractional CTO cost, and what drives the price?
There is no published market price list for this role that can be cited honestly. Prices are agreed individually, often as a monthly retainer, and rarely made public. So instead of quoting unsourced ranges, we suggest a simple method: the cost is the day rate of an experienced technical leader multiplied by the number of days per month, plus a reserve for extra hours.
A reference point for the day rate can be checked. On ARDURA Consulting’s pricing page, roles at architect or lead level (8+ years of experience) are typically priced at EUR 485–650 per day, and cloud architects at EUR 650–835. Those are not prices for a fractional CTO service, which we do not offer; they are rates for roles at a comparable level of seniority from a Polish nearshore provider, useful as an anchor. Local rates in London, Munich or Zurich are typically higher. At the Polish-provider range, the arithmetic looks like this:
- one day a week (about 4.3 days a month): roughly EUR 2,100–2,800 a month;
- two days a week (about 8.7 days a month): roughly EUR 4,200–5,700 a month;
- half-time (about 10–11 days a month): roughly EUR 4,900–7,200 a month.
Treat this as an estimate, not a market fact. What pushes the price up: experience in your sector (financial, medical or industrial systems), having built a team from scratch before, involvement in funding rounds, availability outside the agreed days and accountability for regulatory compliance. What pushes it down: a shorter horizon of accountability, a tightly bounded scope and flexibility about which days are worked.
When comparing with a full-time hire, do not compare day rates. A full-time CTO means salary, employer costs, often equity and several months of recruitment during which decisions are still made without them. A fractional CTO has no recruitment lag and usually no equity, but each day costs more than an employee’s. The fair comparison is total annual cost at a realistic number of days. Our breakdown of team subscriptions, time and materials and fixed price shows how the same logic applies to other engagement models.
Which pricing models make sense?
You will meet three models in practice, and each puts the risk in a different place.
A monthly retainer for an agreed number of days. The most common and usually the best. You pay a fixed amount for, say, eight days a month plus agreed availability for urgent issues. Your cost is predictable and so is the CTO’s income, which supports commitment. The key clauses: what happens to unused days (they lapse, roll over within a cap, or reduce the invoice) and what extra days cost.
A day or hourly rate billed on actual time. Flexible, but with a flaw: the CTO has no reason to get involved on their own initiative, and you have a reason to economise on contact. The CTO role then dissolves into an on-call consultant. This model works for a trial period or for very irregular needs.
A retainer plus a performance component or equity. Common in start-ups that cannot afford the full cash rate. It can work, but it needs precision: what exactly triggers the bonus, who measures the outcome, what happens to the equity on separation. Vague equity terms are a frequent source of disputes that outlast the engagement itself. If you go this way, involve a corporate lawyer, not just your accountant.
Mind the employment-status rules where you operate. In the UK, the off-payroll working rules (IR35) put the status determination on medium and large private-sector clients, so a long-term part-time CTO engagement needs a documented assessment; our article on IR35 and engineers from Poland explains how this plays out with nearshore contractors. Germany has its own strict rules on false self-employment, and other EU countries have equivalents. For a CTO who by definition makes independent decisions within an agreed remit, the risk is usually lower than for a developer embedded in a team, but the contract should describe outcomes and areas of responsibility, not hours of attendance.
What should go into a fractional CTO contract?
The contract has to answer questions that only come up when something goes wrong. Here is the list of clauses worth having before you sign.
Accountability, not a list of activities. “Attends team meetings” means nothing. “Approves architecture decisions above an agreed cost or impact threshold and maintains the decision log” means a lot. List the decisions the CTO owns and those that stay with the board.
Commitment, availability and reserve. Days per month, fixed days or hours of presence, response time for urgent issues, a cap on extra hours and their rate.
Authority. What the CTO can access (repositories, cloud accounts, vendor contracts, budget), whether they can sign purchase orders and up to what amount, whether they can hire and dismiss, whether they represent the company towards vendors.
Conflicts of interest. A fractional CTO usually works for several companies. The contract should rule out work for direct competitors and require disclosure of ties to vendors. If the CTO recommends a software house in which they hold shares or from which they receive a referral fee, you need to know before the decision, not after.
Confidentiality and ownership of work. Documents, decisions, diagrams and any code belong to the company. Make sure the intellectual property assignment is explicit and valid under the governing law of the contract, rather than a vague “all rights pass to the client”.
Handover on exit. A notice period long enough to find a successor, an obligation to hand over access, the decision log, documentation and the list of open risks. Without that clause the knowledge walks out with the person, and the company is back where it started, only with less budget.
Measurable goals for the first quarter. More on that next.
How do you measure whether a fractional CTO is delivering?
A leadership role is hard to measure, but not impossible. Combine three kinds of evidence.
First-quarter outcomes. Before they start, agree what should exist after 90 days. A typical list: an assessment of the system and the team with the main risks, an annual technology budget, a log of key architecture decisions, a hiring plan or a revised vendor model, and an action plan for the next two quarters. If those documents do not exist after three months, the renewal conversation is easy.
Software delivery indicators. Google Cloud’s DORA research programme describes five software delivery performance metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. You do not need all of them from day one, but a good CTO should be able to say which ones they track, where the baseline is and how they plan to improve it. The definitions are in DORA’s guide to the delivery metrics.
Decision quality as the board sees it. Does the board understand what it spends on technology? Have investor questions stopped being surprises? Has the vendor relationship become predictable? These are soft measures, but the CEO knows the answers after a quarter. If the answer is “I’m not sure what he actually does”, the problem lies either with the CTO or with communication, and both need fixing.
A good habit is a short monthly report from the CTO: what was decided, what was measured, the three biggest risks and what they need from the board. One page is enough. A report that cannot be read in five minutes was written for its author, not for the CEO. For a broader view of how a non-technical leader can steer engineering teams well, see our guide for non-technical leaders.
What are the red flags when choosing a candidate?
Some signals should worry you before the contract is signed.
The candidate already knows which technology to pick. Before seeing the system, the team or the budget, they have the answer: “we’ll move to microservices”, “everything goes to cloud X”. A good CTO asks questions first and recommends second. Ready-made answers usually mean the candidate is selling their favourite solution.
Vendor ties that surface by accident. The candidate recommends a particular software house, and only at the third meeting does it emerge that they are a partner in it or receive a commission. Such a tie need not be disqualifying; an undisclosed one is.
No track record of accountability. The candidate has consulted on many projects but has never owned a budget, a team or the consequences of a decision. They may be an excellent adviser, but not a CTO.
Too many parallel clients. Working for several companies is normal. If the candidate has eight, your company gets tired attention between other meetings. Ask directly how many companies they work for and how many days each gets.
Reluctance to write anything down. If the candidate thinks documenting decisions is bureaucracy, all that remains after they leave is a memory. In a part-time role, where the CTO is not around every day, written decisions are the only way the team knows what was agreed.
Eagerness to code on the project. See the next section.
Why shouldn’t a fractional CTO write production code?
The temptation is understandable. An experienced engineer you are paying anyway could “just” build a key feature, fix a bug, or review a change and fix it on the spot. In the short term that looks efficient. Over time it creates three problems.
The first is lost independence. A CTO who writes code is no longer the person who can judge the team’s or vendor’s work objectively. It is hard to criticise an architecture you co-wrote, and hard to hold a vendor to account for defects in a module you patched yourself.
The second is time. With one or two days a week, every hour of implementation is an hour less for decisions, budget, hiring and the board. Implementation always wins the fight for time because it produces fast, visible results. Decisions lose because their effect shows up a quarter later.
The third is a bottleneck. Code written by someone who is in the company two days a week is code nobody else knows well, and it waits for its author whenever it needs to change.
The fix is simple: separate the roles. The CTO sets standards, approves key decisions and checks quality. Code is written by developers: your team, your vendor, or specialists added to the team through staff augmentation if a specific skill is missing. If at some point the company needs an experienced architect every day, that is a separate role with its own budget, not an extension of the CTO’s remit.
When is a one-off audit enough instead of a fractional CTO?
Many conversations about a fractional CTO start with a question that has a short, bounded answer. Typical examples: “Is our vendor doing a good job?”, “What is in the code we are taking over from the previous software house?”, “Will this architecture survive ten times more customers?”, “What do we tell investors about the technology?”. Each can be answered in a few weeks of work by an independent team, without a twelve-month contract.
This is where ARDURA Consulting can genuinely help. We run two fixed-scope packages. The Code Health Audit takes one to two weeks, starts from EUR 4,500 and covers code review and static analysis, architecture assessment, performance profiling, a security review of code and dependencies, and a technical debt estimate, delivered as a written report with a risk map and a prioritised remediation plan. Technical Due Diligence takes two to three weeks, starts from EUR 8,500 and adds the team and delivery process, scalability and infrastructure, open-source licence compliance and risks that matter to an investor or acquirer, with an investor-ready report and a read-out session for your decision makers.
How does that relate to a fractional CTO? In three ways. An audit can replace the CTO if your problem was a one-off: you get an answer and a plan, and your team or vendor carries it out. An audit can precede the CTO: instead of spending the first weeks reading code, a new CTO starts from an independent report and moves straight to decisions. And an audit can complement the CTO when they need an independent outside view, for example before an investor meeting or a vendor change. We described how such an audit runs, including the variant for code written with AI assistants, in AI code audit in two weeks.
A useful test: write down the question you need answered. If it fits in one sentence and has a deadline, start with an audit. If there are many questions, they change every month and they concern future decisions, you need someone on an ongoing basis.
How do the options compare: fractional, full-time, audit or adviser?
The table below brings the criteria together. Use it to start a board discussion, not as an algorithm.
| Company situation | Best option | Why | Typical horizon | Watch out for |
|---|---|---|---|---|
| One specific question about code, architecture or a vendor, with a deadline | One-off audit (e.g. Code Health Audit or Technical Due Diligence) | Bounded answer, fixed scope and price, independent of the team | 1–3 weeks | Someone must own the action plan after the report |
| Small team or external vendor, one product, decisions every few weeks | Fractional CTO, about 1 day a week | Direction, vendor oversight and budget without a full-time salary | 6–18 months | Vague accountability, undisclosed vendor ties |
| Own team of 5–15 people, hiring, setting up the delivery process | Fractional CTO, 2 days a week or half-time | Enough time for people and process, still cheaper than full-time | 12–24 months | Regularly exceeding the commitment signals it is time for full-time |
| Team beyond a dozen or so people, technology as the main advantage | Full-time CTO | Daily decisions and leadership, long-term accountability | Open-ended | Long recruitment; consider an interim CTO meanwhile |
| Crisis: CTO resigned, outages, vendor dispute | Interim CTO, often combined with an audit | Fast stabilisation and preparing a successor | 3–6 months | Handover plan written into the contract from day one |
| You only need answers; decisions stay with the board | Technology adviser | Cheapest access to expertise | Ad hoc | An adviser is not accountable; do not call them a CTO |
Note that rows can be combined. A company hiring a fractional CTO often commissions an audit at the start, so the new CTO has an independent baseline. A company recruiting a full-time CTO may use an interim one in the meantime. The most expensive option is usually no decision at all: months in which nobody owns technology while technical debt and costs grow unchecked.
What does a good first quarter look like?
If you go with a fractional CTO, the first 90 days decide whether the engagement creates value. Here is a plan worth agreeing before the start.
Weeks 1–4: discovery. The CTO gets access to repositories, cloud accounts, vendor contracts and the budget. They talk to the board, to key people in the team and to the vendor. They read the code on the critical paths or work from an audit report if you commissioned one. At the end of the month they present the current state to the board: what works, what is a risk, what we do not know.
Weeks 5–8: decisions. Based on that picture, the CTO proposes three to five key decisions for the next six months: what to fix, build, buy, who to hire, what to change in the vendor relationship. Each decision has a rationale, a cost and an owner. The board approves them or rejects them with reasons.
Weeks 9–12: rhythm. The CTO sets a steady cadence: a weekly review with the team or vendor, a monthly board report and a quarterly budget and risk review. At the end of the quarter the board assesses the engagement against the outcomes agreed at the start and decides on the next period and commitment.
If after the first quarter you find you need more hands than decisions, you can add specialists to the team. On our available experts page we list full-time, part-time and project-based engagement, and our software development services cover full project delivery, starting with a discovery phase. Related topics on building and running software are collected in our software development hub.
What should you remember before you decide?
A fractional CTO is a sensible answer to a real problem: the company needs someone accountable for technology but does not yet need, or cannot yet afford, a full-time leader. It works when the accountability is clear, the commitment matches the task list, the contract anticipates conflicts of interest and separation, and first-quarter outcomes are measurable. It stops working when the team grows, technology becomes the main advantage, or the CTO regularly works beyond the contract.
Remember five things. First, start by writing down the questions you need answered: one question with a deadline means an audit, many changing questions mean a CTO. Second, cost it as day rate times realistic days plus a reserve, and compare total annual cost, not day rates. Third, write accountability, authority, conflicts of interest and knowledge handover into the contract, not hours of attendance. Fourth, do not let your fractional CTO become the best-paid developer on the team. Fifth, review outcomes after a quarter and be ready to change the model as the company grows.
If your first question is “what do we actually have in our code, and is our vendor doing a good job?”, you do not need a twelve-month contract straight away. Review the Code Health Audit and Technical Due Diligence packages or book a short call: we will tell you whether an audit is enough in your situation or whether you really need someone on board.