Technical debt is a decision, not a codebase
The phrase 'technical debt' makes it sound like something engineers accrue while typing. In practice, the debt that actually hurts a company was taken on in a meeting — often a short one, often by a non-technical founder doing their best with the information available, often on a Tuesday.
The twelve below are the decisions we most often find at the root of an expensive correction. They share a shape: cheap to get right at the time, disproportionately expensive to reverse later, and rarely obvious as consequential in the moment.
The four that compound fastest
If you only get four of these right, get these four:
- 1. Build versus buy. The default answer is buy, and the exception is narrow: build only when the workflow is a competitive advantage rather than merely unusual. Building to save on licence fees trades a predictable cost for an unbounded one.
- 2. The first engineering hire. A first hire sets the culture, the stack and the hiring bar for everyone after them. Hiring a generalist when you need a specialist — or a specialist when you need someone who will do everything — is an 18-month correction, because you inherit both the person and their architecture.
- 3. The data model. Almost every rebuild we have been asked to quote traces back to a data model shaped around the first customer. It is the single most expensive thing on this list to change, because it touches everything.
- 4. Vendor lock-in. Not whether to use vendors — you should — but whether you can leave. Build directly against one provider's SDK and switching becomes a rewrite. Build behind a thin abstraction and it becomes a configuration change.
The eight that follow
- 5. Architecture at seed stage. The failure mode is not under-engineering; it is building for a scale you do not have while ignoring the constraints you do.
- 6. Security posture before enterprise deals. Your first enterprise prospect will send a security questionnaire. Answering it honestly six months early is a project; answering it dishonestly is a liability.
- 7. When to rewrite. Rescue is right more often than teams expect. Slow delivery is usually a pipeline problem, not an architecture one.
- 8. How to scope an agency. An agency with no technical counterpart on the client side grades its own homework. That is not a criticism of agencies; it is a structural problem with the arrangement.
- 9. Technical diligence readiness. Investors and acquirers ask a predictable set of questions. Knowing your own answers before they ask changes the negotiating position materially.
- 10. The AI provider decision. Free tiers of major providers typically use submitted content to improve their products; paid tiers contractually do not. Teams discover this in a pilot and inherit it into production.
- 11. What to measure in production. Change lead time, error rate and deploy frequency tell you more about engineering health than any status meeting.
- 12. When to stop using a fractional CTO. A good engagement names its own exit condition. One that does not is selling you a dependency.
What the DORA research says about which signals matter
Google's DORA programme has been the most rigorous public research on software delivery performance for over a decade, surveying tens of thousands of professionals. Its central finding is that four measures predict both delivery performance and organisational outcomes: deployment frequency, lead time for changes, change failure rate, and time to restore service.
For a founder without a CTO, that is unusually actionable. You do not need to evaluate architecture to know whether engineering is healthy — you need four numbers, and you can ask for them today. A team that ships weekly, gets a one-line change to production in under a day, and recovers from failure in under an hour is functioning. A team where any of those is measured in weeks has a problem worth investigating, whatever the roadmap says.
| Deploy frequency | How often code reaches production |
|---|---|
| Lead time | Commit to production for a one-line change |
| Change failure rate | Share of deploys causing a problem |
| Time to restore | How fast you recover when one does |
The decision-count test
The question underneath most of this is not 'do we need technical leadership' — you do — but what shape it takes. The test we use is a count. List the decisions above that are genuinely live in the next two quarters. Fewer than one a week and a full-time CTO will spend a lot of time inventing work; more than that and a fractional arrangement becomes a bottleneck.
As a rough marker, companies under about 25 engineers usually do not have enough sustained CTO-level work to justify the role. The exception is when you are raising, and the CTO is part of the story investors are buying.
Where we would tell you not to hire us
If your list of live decisions is short and mostly about shipping features faster, you do not need a fractional CTO. You need a strong lead engineer, which is a cheaper hire and a faster search. We will tell you that on the call rather than after the invoice.
Equally, if you are past 25 engineers, raising a round where technical leadership is part of the pitch, or fielding enterprise security reviews weekly — hire full-time. Fractional at that point is a bottleneck dressed as a saving.