The Decision RecordTechnology leadership, strategy and architecture for founders and executives
Decision frameworks and long-form guides for the people who answer for technology: founders, CEOs, boards, investors and the engineering leaders who report to them. Written to help you decide, whether or not you work with Comtau.
The title tells you very little. What matters is which decisions the CTO owns and answers for. This guide breaks the role into five accountabilities you can check against your own company.
Decide whether to build or buy software with five questions on differentiation, market fit, total cost of ownership, risk and exit, plus a weighted scorecard.
How to reduce technical debt deliberately: find the debt that charges interest, price it in delivery terms, then repay, contain or accept it and govern it.
·8 min read
02 / Strategic topics
Three areas where technology becomes a leadership decision
Each topic starts from the questions leaders actually ask, and every article ends by connecting the answer to a decision you can make.
Build versus buy is really a question about where to spend scarce engineering attention. This framework replaces the usual debate with five questions, a decision matrix and a scorecard you can take into the meeting.
Both titles say 'technology', and in a small company one person often does both. They are still different jobs, with different customers, measures and risks. Here is how to tell them apart and decide which one your company needs.
Most technology roadmaps fail in one of two ways: they are feature lists with dates, or strategy documents nobody can execute. This framework builds one that connects business outcomes to engineering work, and stays honest as plans change.
·7 min read
04 / Practical guides
Frameworks you can take into the next planning meeting
Decision frameworks, checklists and step-by-step methods. Each one names what you leave with.
You leave withA five-part accountability map and a checklist to see which parts of the CTO role your company has covered.
Technology leadership
05 / Architecture & engineering
For the people who answer for the system
Technical debt, system health and the evidence a buyer or investor will ask for, written for CTOs, engineering leaders and the executives they report to.
Technical debt is not a moral failing and it is never zero. The goal is to stop paying interest on the debt that slows the business down, while delivery continues. This deep dive sets out how to find that debt, price it and pay it down in a way leadership can support.
Technical due diligence rewards companies that know their own system. This guide explains what investors and acquirers examine, gives you a ten-area checklist and a data-room index, and shows which red flags to fix before anyone asks.
Decide whether to build or buy software with five questions on differentiation, market fit, total cost of ownership, risk and exit, plus a weighted scorecard.
CTO vs CIO explained: who owns product technology and who owns business systems, where the roles overlap, typical reporting lines, and which one you need.
A practical method for building a technology roadmap: start from business outcomes, assess the current system, sequence work in horizons and review monthly.
How to reduce technical debt deliberately: find the debt that charges interest, price it in delivery terms, then repay, contain or accept it and govern it.
A technical due diligence checklist for founders: what reviewers examine, the documents to prepare, red flags to fix early and how to run the review calmly.
What a CTO is accountable for: technology strategy, architecture, the engineering team, delivery and technical risk, and how the role changes with growth.