Without an in-house CTO, safe decisions rest not on heroics or on “the most experienced developer” but on a procedure: decisions are split into easily reversible ones and those that are expensive to undo; for the latter you record context, options and a review condition; the repository and infrastructure have minimal guardrails; and an outside view is brought in at agreed points. The founder stays the owner of key access throughout. Below is a procedure the team can introduce and run on its own.
Contents
What is actually missing without a CTO
A small team without a technical director can usually write code. What is missing are the functions a CTO performs besides programming. If nobody is explicitly assigned to them, they do not disappear — they are performed by accident, by whoever hits the problem first.
Owner of technical decisions
- What happens without an owner
- Decisions are made in chats and forgotten; six months later nobody remembers why
- Minimal substitute
- A decision log in the repository
Risk filter
- What happens without an owner
- Decisions that are expensive to undo get made as quickly as small ones
- Minimal substitute
- The two-classes-of-decisions rule
Link between business and technology
- What happens without an owner
- The team optimises what is interesting, not what matters to the product
- Minimal substitute
- A regular short priorities review with the founder
Keeper of access and continuity
- What happens without an owner
- The domain, cloud and repository are registered to developers' personal accounts
- Minimal substitute
- All key accounts belong to the company, with an access list
Assessing candidates and contractors
- What happens without an owner
- Hiring on impressions, accepting contractor work without checking it
- Minimal substitute
- An outside view at agreed points
Two classes of decisions
Most technical decisions are easy to reverse: a date library, how a form is laid out, a variable name. Make them quickly, by whoever is doing the task. But some decisions cost months of work to undo or put data at risk. Those need a different procedure.
Easily reversible — the team decides now
- Internal libraries and utilities
- UI component structure
- Developer tooling
- Task order within a sprint
Expensive to undo — write it down, get a second view
- The data model and choice of database
- Authentication and how personal data is stored
- Cloud provider and hosting region
- Mobile stack, multi-tenant product architecture
- Contracts with API and platform vendors
A simple test for borderline cases: what happens if the decision turns out wrong in six months? If the answer is “we'll change it in a day”, it is reversible. If the answer contains “data migration”, “rewrite”, “notify users” or “terminate the contract”, it belongs to the second class.
A decision log: a short record instead of memory
For second-class decisions the ADR (architecture decision record) format described by Michael Nygard in 2011 works well: a short document in the project repository with Title, Context, Decision, Status and Consequences sections. Records are numbered, numbers are never reused, and a reversed decision is not deleted but marked as superseded.
Nygard explains the point of the log: a newcomer who does not know why past decisions were made can only accept them blindly or reverse them blindly — and both are bad. For a team without a CTO, the log also stands in for the missing leader's memory.
Problem
What needs deciding and why now; the business and team constraints.
Options
Two or three real options, including “change nothing”, with the pros and cons of each.
Decision
What was chosen and why; what was deliberately rejected.
Owner
Who is responsible for carrying it out and who to ask.
Review condition
A date or event that should reopen the decision: load growth, a new market, a team change.
Minimal guardrails
Guardrails lower the cost of a mistake, whoever makes it. They do not need an in-house architect — they are set up once and checked periodically.
- The repository, domain, cloud accounts, app store and payment accounts belong to the company; the founder has owner rights.
- Two-factor authentication is mandatory for everyone. On GitHub an organisation owner can require it; outside collaborators without it are removed from the organisation.
- The main branch is protected: changes go through a pull request with approval and required automated checks; force pushes and branch deletion are blocked.
- Secrets are not stored in the repository; each environment has its own keys.
- Backups run automatically, and restoring from them is tested in practice, not just in the settings.
- Production and test environments are separate; customer data is not copied to test without anonymisation.
- When an employee or contractor leaves, access is revoked from a list, not from memory.
- Dependencies are updated regularly, not only after an incident.
Rhythm and metrics without bureaucracy
The procedure works if it has a rhythm. A short regular meeting is enough, where the team and the founder go through new log entries, open risks and incidents for the period.
To see whether delivery is improving, you can rely on the metrics from the DORA research programme. There are five:
- Change lead time — from commit to running in production.
- Deployment frequency.
- Failed deployment recovery time.
- Change fail rate — the share of deployments needing immediate intervention such as a rollback or hotfix.
- Deployment rework rate — the share of unplanned deployments triggered by an incident.
DORA warns explicitly: do not turn the metrics into targets and do not compare teams — their purpose is to show your own team's trend. For a small team they are a convenient way to discuss process quality with the founder without technical detail.
Incidents are reviewed in writing and without blame. The Google SRE book defines a postmortem as a written record of an incident, its impact and the actions taken, and lists triggers such as data loss of any kind, user-visible downtime and cases where a person, not monitoring, discovered the problem.
When to bring in an outside view, and when to hire a CTO
An outside view is useful at specific points rather than all the time. Agree on them in advance so that asking for advice is not seen as admitting weakness.
- Before a second-class decision, if the team has no experience in that particular area.
- Before handing the product to a contractor or accepting their work.
- Before fundraising, when the product will be examined from outside.
- After a serious incident, especially one involving data.
- When the team has argued for a long time and cannot choose between options.
An in-house CTO is needed when technology is the core of the product, strategic technical decisions arrive as a steady stream, and the team has grown enough to need hiring, development and people management. External mentorship does not replace that role: it helps make and check decisions, but does not take on people management.
InterLAB technical mentorship means regular consultations and reviews of decisions and pull requests within an agreed scope, with a decision log and next steps for each period as the result. Frequency and hours are fixed in the contract; there is no “24/7 availability” and no CTO responsibility by default — broader authority is possible only by separate agreement. The cost is determined after a brief and an agreed scope.
