A Technical Co-Founder You Do Not Have to Give Equity To
For founders who can see the product clearly but have no way to judge a technical decision, a quote, or a developer's work. A senior engineer on your side of the table, for a few hours a month.
- Typically 10 to 40 hours a month
- Flat monthly retainer, no hourly meter
- We will tell you when you have outgrown it
What It Feels Like Without One
Every one of these is a decision that is cheap to get right at the start and expensive to correct two years later.
What a Fractional CTO Actually Does
Not strategy documents. Specific decisions, reviewed work, and someone accountable for the technical answer you give other people.
Architecture and technology choices
Which platform, which stack, what is built versus bought, where the data lives, how it scales and what it will cost to run. Decided for the product you are building, not for the tools somebody happens to like.
Vendor and freelancer oversight
Reviewing quotes, reading the code your existing developers ship, checking that estimates are honest and progress is real. The single most common reason founders start this engagement.
Technical due diligence
Getting your technology ready to be examined before a raise, and sitting in the room when investors ask. Also diligence in the other direction, when you are about to acquire or depend on somebody else's system.
Hiring your first engineers
Writing a job description that describes the job, screening candidates, running the technical interview, and calibrating what the offer should be. Your first engineering hire sets the standard for everyone after them.
Roadmap and technical debt
Turning “the developers want to refactor” into a business trade-off with a number on each side. Sometimes the answer is to do it now, sometimes it is to live with it deliberately for another year, and knowing which is the job.
Being the technical answer
When an enterprise customer sends a security questionnaire, when a partner asks how the integration works, when your board wants to know why a release slipped. Someone answers, credibly, without you having to relay it.
Decide Once, Cheaply, Instead of Twice, Expensively
A handful of early technical decisions set the ceiling on what a product can become. Choosing a database that cannot do what you will need at scale, picking a framework with a shrinking community, building multi-tenancy in a way that cannot support enterprise customers — none of these hurt in month one. They all hurt in year two, and by then they cost a rewrite.
The work here is unglamorous and mostly consists of asking better questions than the ones being asked. Every recommendation is written down with the reasoning and the trade-off, so you can show it to a developer, an investor or your next CTO and they can see why.
- Boring, well-supported technology by default; novelty only where it earns its place
- Choices that a future engineer can be hired to work on, not a niche nobody knows
- Running costs modelled before committing, not discovered on an invoice
- Data and compliance obligations identified before they become somebody's emergency
Watching the Work You Are Paying For
If you already have developers — an agency, a freelancer, a first hire — this is usually where most of the hours go.
What we actually check
- Whether the code being committed matches what is being reported as done
- Whether estimates are consistent with what similar work genuinely takes
- Code review on the parts that carry real risk: payments, authentication, personal data
- Whether tests exist, run, and would catch anything if they failed
- Whether documentation would let a successor take over without a crisis
- That accounts, repositories and store listings are in your name and not theirs
How we handle it with your developers
- We introduce ourselves as your technical counterpart, not as an auditor sent to find fault
- Concerns go to them first where that is fair, so nobody is ambushed in front of you
- When the work is good we say so plainly, which is information you cannot get anywhere else
- We translate their constraints into business terms instead of taking sides
- If the relationship genuinely needs to end, we say so once, clearly, with the evidence
Where the concern is the codebase itself rather than the people, the right starting point is a fixed-price code audit — a single deep inspection with a written verdict, rather than an ongoing retainer.
Technical Due Diligence, Before Someone Else Runs It
Investors past the seed stage will have an engineer look at your technology. The goal is that nothing in that review is a surprise to you.
1. Find out what is actually there
A structured review of the codebase, infrastructure, security posture, dependency licensing and data handling. This is the same inspection an investor's technical advisor will run, done several months earlier and with time to act on it.
2. Fix what is cheap and disclose what is not
Some findings can be cleared in a fortnight: secrets in a repository, an unpatched dependency, a missing backup policy. Others are structural and will not be fixed before a raise. Those get disclosed openly with a costed plan attached, which reads far better than being found.
3. Put the story in writing
An architecture overview an investor's advisor can read in twenty minutes, a security summary, a technical debt register with costs, and a scaling narrative that is defensible rather than aspirational. Written in plain English so you can present it yourself.
4. Be in the room
We join the technical diligence call and answer directly. Founders lose credibility on these calls by guessing, and gain it by saying “that is a known weakness, here is the plan and the cost”. An experienced investor is testing whether you know your own system, not whether it is perfect.
Your First Engineer Sets the Standard for Everyone After
The hardest hire a non-technical founder ever makes, because the one skill you need to assess is the one you do not have.
Define the actual role
Most first job descriptions list twelve technologies and describe nobody. We work out what the first hire genuinely needs to do in their first year, which is usually a generalist who ships rather than a specialist in your current stack.
Screen and interview
We sit in on technical interviews and run the assessment, using a realistic exercise rather than a puzzle. Afterwards you get a plain-language read on each candidate: what they are strong at, where the risk sits, and what they would need around them.
Set them up to succeed
An onboarding plan, a first month with a real and finishable objective, and a technical counterpart they can talk to while they find their feet. We also stay available afterwards so their first architectural decision is not made alone.
How Many Hours This Usually Is
Indicative shapes, not a price list. A flat monthly retainer for an agreed block of hours, three months to start, then month to month with 30 days notice.
Advisory
~10 hrs / month
Roughly $2,000 a month. A weekly call and a technical voice on call for the decisions that come up.
- One scheduled call each week
- Reviewing quotes and proposals before you sign
- Architecture decisions as they arise
- Answers to questions within one business day
Embedded
~20 hrs / month
Roughly $3,800 a month. The level most founders settle at once there are developers to oversee.
- Everything in Advisory
- Ongoing code review of your vendor or in-house work
- Roadmap and technical debt planning
- Security questionnaires and customer technical queries
- Interview support for engineering hires
Intensive
~40 hrs / month
Roughly $7,000 a month. For a fundraise, a replatform, or a rebuild of the team.
- Everything in Embedded
- Full technical due diligence preparation
- Attendance at investor and board technical sessions
- Running a hiring round end to end
- Hands-on prototypes where a question needs proving
Figures are indicative starting points rather than a quote. We review the level every quarter and will propose reducing it when the work no longer justifies it — a retainer nobody uses is the fastest way to lose a client who would otherwise have stayed for years. More detail on the pricing page.
When You Need a Full-Time CTO Instead
This engagement has a natural end, and the responsible thing is to name it in advance rather than hold on past it.
A fractional CTO is the right call while
- Technology is how the product is delivered rather than the product itself
- The engineering team is under roughly six people, or does not exist yet
- The big technical decisions are occasional rather than daily
- You are working with an agency or a small number of contractors
- A full-time salary plus equity is not something the business can carry yet
You have outgrown it when
- The technology itself is the differentiator and the hard problem
- You are hiring engineers faster than about one a quarter
- The team is past six or eight people and needs daily leadership
- Technical decisions are needed in the moment, in the room, several times a week
- You need someone who owns the outcome rather than advising on it
When you reach that point we will say so, help you write the role, run the interviews and hand over cleanly to whoever you hire. If you need building capacity rather than advice, a dedicated team is the better instrument — the two work perfectly well side by side.
Fractional CTO Questions
How many hours a month is this, realistically?
Between 10 and 40 hours a month for most founders, with 15 to 20 being the most common. It runs at the top of that range early on, while architecture is being decided and a vendor or first hire is being chosen. Once the direction is settled and a build is running it usually drops to a weekly call plus code review and whatever comes up. We review the number every quarter and we will suggest reducing it when the work no longer justifies it.
Do you write code in this engagement?
Rarely, and only where writing something is genuinely the fastest way to answer a question: a proof of concept, a spike on a risky integration, or a reference implementation for your developers to follow. If you need sustained hands-on delivery you want a dedicated team instead. Paying senior advisory rates for routine production code is a poor use of your money and we will say so.
Will you review the work of a developer we already have?
Yes, and it is less awkward than founders expect, because competent developers usually welcome a technical counterpart who can explain their constraints to you in your language. We review work on its merits, we raise concerns with them before we escalate where that is fair, and we do not go hunting for faults to justify a retainer. When the work is good we say so plainly, which is itself information you currently have no way to obtain.
Can you handle technical due diligence for investors?
Yes. We prepare the material investors actually ask for: an architecture overview, the security posture, the dependency and licensing position, known technical debt with costs attached, and a credible scaling story. We also join the diligence call and answer the technical questions directly. What we will not do is describe a system as something it is not, so anything material is disclosed with a remediation plan beside it, which is what an experienced investor is looking for anyway.
When do we genuinely need a full-time CTO instead?
When the technology is the product rather than the way the product is delivered, when you are hiring engineers faster than roughly one a quarter, or when technical decisions need somebody in the room all day rather than a few hours a week. The same applies once the engineering team passes about six or eight people, at which point leading it is a full-time job. We will tell you when you have reached that point and help you hire the person.
How is it billed, and what is the minimum commitment?
A flat monthly retainer for an agreed block of hours, rather than hourly billing. Three months to start, then month to month with 30 days notice. The flat fee matters more than it sounds: if you are weighing up whether a question is worth an invoice, you will not ask it, and unasked questions are exactly where the expensive mistakes live.
Get a Technical Opinion You Can Actually Trust
Tell us the decision in front of you — a quote to assess, a developer to evaluate, an architecture to choose. The first conversation costs nothing.