A small business with nobody to settle its technical choices always ends up having its suppliers settle them. A part-time CTO answers exactly that problem: giving the business technical leadership a few days a month, without hiring full time a profile it could neither keep busy nor assess.
The most common misunderstanding concerns what the role is for. People picture an experienced developer who costs less because they come in less often. That is not the job. A part-time CTO is not there to make code cheaper: the job is to decide just before the money is spent.
What a part-time CTO does (and does not do)
The scope fits into three verbs.
- Settle. Build or buy, this supplier or that one, rebuild or extend. Decisions whose cost is counted in years of commitment, and which are often taken on the word of the person selling.
- Frame. Turn a business need into a brief a supplier can price without interpreting it, and set in advance the criteria by which the work will be recognised as done.
- Check. Read a quote, an architecture, a maintenance contract; confirm that what is delivered matches what was bought. It is the most neglected part, and the one that pays for the engagement fastest.
What the role does not cover should be said just as plainly. A part-time CTO does not take the keyboard from the development team, does not run desktop support, and does not replace a managed-services provider. If that happens, the engagement was badly framed: the business pays for leadership to obtain execution capacity, and ends up with neither.
The boundary with the head of IT deserves to be drawn. The CTO carries the technology of the product or service the business sells; the CIO carries the IT that keeps the business running — devices, email, management software, security. In a small business the two are often confused, and a part-time CIO answers the second question far more than the first.
Five signs that a small business needs technical leadership
The size of the business says almost nothing. The useful signs are elsewhere.
- Quotes cannot be compared. Two suppliers answer the same need with gaps nobody inside can explain. The decision is then made on price, or on rapport.
- The product depends on one person. A single developer, employed or freelance, is the only one who understands the code. Their departure would be a standstill.
- Projects end without anyone knowing whether they succeeded. With no criteria written at the start, delivery counts as acceptance.
- Technical debt has become a board-level subject. Each new feature costs more than the last, and nobody can say why.
- A funding round, a sale or an audit is coming. Someone is about to ask precise technical questions, and the business has nobody to answer them with authority.
Some signs point the other way. A business whose IT consists of well-chosen off-the-shelf software does not need technical leadership: it needs a good supplier and a clear contract. And a business whose technical decisions have become daily has already outgrown part-time: it needs someone on site.
Part-time CTO, freelance CTO, outsourced CTO: the differences
The three terms are used as synonyms. They do not describe the same thing, and the difference lies less in the contract than in what the business is actually buying.
| Arrangement | What is bought | Cadence | Main risk |
|---|---|---|---|
| Part-time CTO | A leadership function, a few days a month | Regular, over time | A scope that drifts into execution |
| Freelance CTO | One person, for an assignment or a phase | Intense, then nothing | Dependence on one individual, with no cover |
| Outsourced CTO | A function entrusted to a firm, with team continuity | Set by the contract | Distance from the business if the contact changes |
A freelance CTO is often the right choice for a bounded assignment: auditing code before a sale, framing a project, hiring a first team. An outsourced CTO brings what an independent cannot guarantee — continuity if the person changes. Part-time stands apart by its duration: it installs a function rather than completing an assignment.
The choice therefore depends on the question being asked. A one-off question calls for an assignment. A question that comes back every month calls for a function.
How an engagement runs: cadence, deliverables, governance
A part-time technical leadership engagement rarely starts with technology. It starts with an inventory: what the business has built, bought and handed over, and to whom. Without it, every decision is taken blind.
The cadence comes next, and it matters more than the volume. A regular, predictable presence — a fixed day each week, or two days a month on known dates — is worth more than broad but unpredictable availability: teams and suppliers learn to prepare decisions for that slot.
The expected deliverables are few, and they must exist in writing:
- a map of what exists — applications, suppliers, contracts, access rights — kept up to date;
- a short technical roadmap, tied to the business’s objectives and budget;
- a decision log: what was settled, why, and what was ruled out;
- acceptance criteria for every project handed to a supplier.
Governance, finally, must be explicit. The part-time CTO reports to the managing director, not to a supplier or a project manager, and has access to contracts and invoices. Without that access, the role advises; it does not lead.
When the roadmap leads to building something, the two roles are better kept apart: whoever frames and checks must be able to say no to whoever develops. That is why, at Maeliom, framing sits with Maeliom Consulting and delivery with Maeliom Build — and why a framing exercise can conclude that nothing should be built.
The limits of the model
Part-time leadership has three limits, and an honest engagement names them from the start.
- Responsiveness. An incident on a day without presence waits. The model assumes a supplier or a team able to keep operations running, with written escalation rules.
- Depth. A few days a month are enough to settle and check, not to know every line of code. On specialist subjects, a part-time CTO brings in a specialist rather than replacing one.
- Duration. Once technical decisions become daily, part-time slows the business down instead of protecting it. That is the sign it is time to hire.
That last point matters most. A part-time CTO who does the job well prepares the hire that will make the role unnecessary: writing the job description, sitting in on interviews, handing the map and the decision log to whoever takes over. For a young company, CTO as a service asks the same question from another angle: what has to be settled before hiring.
Common questions
How much time does a part-time CTO give a small business?
There is no standard volume. The cadence follows the number of decisions to take and suppliers to manage. What matters is regularity: a predictable presence lets teams prepare decisions for that slot.
Can a part-time CTO write code as well?
They can, but that is not what the function is for. An engagement that drifts into execution deprives the business of what it was buying: someone who settles, frames and checks other people’s work.
How does it differ from a part-time CIO?
The CTO carries the technology of the product or service being sold; the CIO carries internal IT — devices, management software, security, suppliers. In a small organisation one person can cover both, provided it is clear which of the two questions is being addressed.
When should part-time give way to a hire?
When technical decisions become daily, or when the business builds its own product with an in-house team. Part-time then serves to prepare that hire and to hand over what has been documented.