Connect product decisions with technical ones.
I work with the founder and team on decisions that affect the product, architecture, delivery, and cost. This is not advice from a distance: I work in the current documents, plans, and problems.
Start a CTO-support briefUseful when
- A founder needs a technical partner, but a permanent role is not yet justified.
- Architecture, roadmap, delivery, hiring, and commercial pressure are pulling in different directions.
- The team is busy, but decisions and responsibilities are not clear enough.
- A migration, launch, or other important change needs careful planning and a path back if something fails.
Typical outcomes
- Product and architecture decisions that are explained and recorded.
- A delivery plan matched to the team's real capacity.
- Clearer responsibilities and a list of important technical risks.
- Fewer differences between the plan, the implementation, and what reaches production.
ICE
How the support works
Understand
Read the product, code, plans, and current problems and speak with the people involved.
Prioritise
Choose the decisions that can change the outcome and leave work that can wait.
Work directly
Contribute to specifications, architecture, estimates, launch plans, and incident decisions.
Transfer
Document context and decisions so the team does not remain dependent on one person.
What this is not
- A ceremonial title without access to the real product and technical decisions.
- Long-term replacement of internal responsibility and team development.
- Validation of deadlines or results that the real situation does not support.