Fractional CTO: what it is and when your company needs one

Not every company needs a full-time CTO, but every company needs sound technical decisions. It is also the clearest way to explain a fractional CTO: someone who owns those decisions without being there every day. Whether or not anyone holds the title, those decisions are being made somewhere in your company.

My path runs from software developer to co-founder. Along the way I have made infrastructure, team and product decisions for clients and for my own companies. I also run a software agency, PNZ Medya, as its general manager. So I know the side that writes proposals from the inside. This post covers what a CTO actually does, when the role needs a full-time person and what to do when it does not.

What does a CTO actually do?

CTO stands for Chief Technology Officer. It is the senior executive responsible for a company's technology decisions, the person who represents the technical side at the leadership table.

Job descriptions vary from company to company. In a small or mid-sized business, though, the work falls roughly into four areas:

• Technology and architecture: which infrastructure to use, what to buy off the shelf and what to build.
• Team and vendors: who to hire, and which agency or freelancer gets the work.
• Risk and ownership: security, backups, access rights, and who holds the code and the accounts.
• Translation: turning business goals into a technical plan, and technical risk into language leadership understands.

Writing code is not on that list. In early-stage companies the CTO often writes code too, but that is not what defines the role. What defines it is who answers for the outcome of a technical decision.

CTO vs CIO vs tech lead

The CTO is most often confused with the CIO. A CIO (Chief Information Officer) looks after internal systems: accounting, data, internal communication and operational tools. A CTO looks after customer-facing technology and the product. In a small company both hats are usually worn by the same person.

The difference from a tech lead is one of scope. A tech lead protects the team's day-to-day technical quality. The CTO decides which direction that team takes, on what budget and with what level of risk.

Do you need a full-time CTO?

A full-time CTO is a hard and expensive hire. So first check whether the need is really full-time. The distinction I use is simple: is technology your product, or is it a tool that runs your business?

Say technology is the product: you sell software or a platform and are building your own engineering team. Then technical decisions are made every day. You need someone who makes those calls daily, builds the team and stands behind the outcome.

If technology is a tool that runs your business, the picture changes. Your website, online store, mobile app or internal software may be built by an agency or freelancers. In that case technical decisions come at specific moments, not every day. Those moments are usually easy to spot: starting a new project, changing vendors, a problem that keeps growing, or a major investment.

In that second group, a full-time CTO often means an expert who waits for most of the week. Leaving decisions without an owner is the bigger risk. The option between the two is a fractional CTO.

If you are building your own engineering team, the post on roles and weekly rhythm may also help.

Where things go wrong without a CTO

In companies without a full-time CTO, the problem is usually not missing code but decisions nobody owns. These are the four situations I see most often:

• Technology is chosen based on what the vendor knows, not on what the company needs.
• Nobody is sure who holds the code, the server and the domain.
• There is no technical eye to compare incoming proposals.
• Security, backups and access rights are nobody's responsibility.

The first one does not require a vendor with bad intentions. I sit on the side that writes proposals, so I can say this plainly. Every team works faster and with less risk in the tools it knows, and its recommendation naturally leans that way. The problem is accepting that recommendation without checking it against what the company needs.

The second one usually surfaces when a relationship ends. You part ways with a vendor and find that the domain sits in someone else's account. The code was never handed over either. That is why the first question in any software project should be: who keeps the code and the domain?

What a fractional CTO does, and what they don't

A fractional CTO is a technical executive who works with a company part-time but carries responsibility for its technical decisions. The word fractional describes the time, not the responsibility. A good fractional CTO does not make a recommendation and step back; they stand behind the decision.

These are the deliverables I work with in this role:

• A technical status report: infrastructure, code, access rights and risks.
• A technology and architecture roadmap.
• A technical review of vendor and agency proposals.
• Checklists for code, security and backups.
• Technical representation in regular leadership meetings.

What the role does not do matters just as much. The focus is decisions and direction; writing code is not the job. If development is needed, it is planned with your team or a development team. If what you need is more hands rather than strategy, you are looking for developers, not a CTO.

The working rhythm is set by the need: regular weekly meetings, with more intensive support in critical periods. The scope is put in writing after the first conversation. Any work that requires access to your systems and data starts with a confidentiality agreement.

Who is it for?

• Companies that have their software built by an agency or freelancers.
• Startups without a technical co-founder.
• Businesses that want a clear view of their technical position before an investment or a large project.
• Executives who are not sure their technology budget is paying off.

If your product is mature and you manage a large engineering team, you most likely need a full-time technical executive. The fractional model suits periods when the need for decisions is intense but intermittent.

A ready prompt to compare software proposals

Even without a CTO, you can put incoming proposals on the same scale. Paste the proposals you have into the prompt below and use it with an AI assistant. Treat the output as a list of questions for your vendors, not as a decision.

Below are the proposals I received for a software project. My technical knowledge is limited.

Your task:
1. Compare the proposals in one table: scope, technology to be used, delivery steps, maintenance and support, payment plan.
2. Review ownership terms under a separate heading: whose name the domain will be registered in, whether the source code is handed over, who keeps admin access to servers and service accounts.
3. List anything that is unclear or missing from the proposals.
4. Write at most five questions I should ask each vendor.

Do not assume anything that is not in the proposals; mark anything you are unsure about as unclear. Do not decide which proposal is better, only compare.

Proposals:
[paste the proposals here]

The slowest part of the comparison is usually scope. If a proposal looks cheap, start by checking what it leaves out.

Most software projects struggle not because of code but because of scope.

In short, a CTO is not a title but the owner of technical decisions. If those decisions are made every day, you need someone full-time. If they come at specific moments, you need someone who is there at those moments. If you would like to work through your technical decisions together, here is how a fractional CTO engagement works.