A fractional CTO is worth most in the month before a decision you can't undo
A fractional CTO is a senior technical lead you retain part-time, on a regular cadence, before you can justify a full-time hire. You pay for judgement on the decisions that are cheap to make and expensive to unmake, and most founders face several of those in their first year.
The role covers four kinds of decision
A full-time CTO owns the technology and the team that builds it. A fractional one owns the calls, and leaves the building to your engineers or a delivery partner. In practice the calls fall into four groups.
Architecture. Which platform, which language, which data model, and which of those you will still be able to change in three years. Most architecture decisions turn out to be decisions about what stays changeable.
Vendors. Build, buy or borrow. Each has a cost, and one of them is always left out of the spreadsheet, usually the cost of leaving.
Hiring. What to look for, when to hire, and what a senior engineer is for. A first engineering hire shapes the codebase for years, and a founder without a technical background has little to judge the interview by.
The technical side of money. The white paper, the technical half of the pitch deck, the answer to the question a diligence call will ask. Sales calls too, when the buyer brings an engineer and you need someone on your side of the table.
The expensive mistakes are made early
Most costly technical decisions are made early, with incomplete information, by people who won't find out for eighteen months whether they were right. Nobody makes them carelessly. The information just isn't there yet.
That is the case for paying for advice before you have a product. The platform choice, the first hire and the vendor contract all happen before there is a team to second-guess them. By the time a full-time CTO arrives, those decisions are the codebase.
A cadence works when the calls pile up
There are two ways to buy this, and they suit different weeks.
A regular cadence means recurring sessions, so the advice arrives while each decision is still open. It suits a team making a lot of consequential calls in a short period. That describes most teams in the months before a launch or a raise.
A defined piece of work suits one question. A document review, an architecture opinion, a research question answered, a stretch of R&D. It's scoped and priced up front, and it ends.
Most people arrive describing one and need the other. Working that out belongs in the first conversation, and nobody should have to get it right in advance.
Four questions to ask before you hire one
Do they still build? Advice from someone whose team ships software is tested every week. Ask what their people delivered this year.
Will they sit in the room? A fractional CTO who only writes memos can't answer the engineer your buyer brings to the sales call.
Will they tell you when you need less? Sometimes two conversations settle it. Someone who says so is more useful than someone selling a retainer.
What do they ask for first? A conversation and a mutual NDA is the right start. Nobody needs your repository to tell you whether they can help.
How MLabs does it
MLabs builds and verifies software for fintech and on-chain finance. Ben Hart leads the advisory work, and it draws on the same engineers who do the delivery. They ported Juspay, India's largest payment gateway, from PureScript to Haskell. They built the first generation of Cardano's DeFi. Their open-source tooling is public at github.com/mlabs-haskell. The firm has also sat on the other side of the table, as named partners in fundraises for Liqwid and Clear Contracts.
The first call is free. Tell us what you are deciding and what it would cost to get it wrong.
