Консалтинг
CTO на аутсорс: когда стартапу нужен технический директор
Нетехнический фаундер регулярно принимает технические решения без права на ошибку. CTO на аутсорс — не роскошь для стадии roundА, а способ не платить за эти ошибки позже.
Коротко
CTO на аутсорс нужен в трёх ситуациях: до найма первого разработчика (выбор стека и реалистичная оценка стоимости), когда команда уже есть, но решения принимаются ситуативно без единого технического видения, и когда нужен технический голос для инвесторов. Формат — частичная занятость, обычно 15–25 часов в месяц, и он не заменяет штатного разработчика, если продукту нужны решения в течение часов, а не дней.
Решения, которые идут не так без технического голоса
Нетехнический фаундер принимает технические решения постоянно, даже когда не осознаёт это как техническое решение: с каким подрядчиком подписать договор, какую архитектуру предлагает разработчик на собеседовании, реалистичен ли срок, который назвал агентство. Без человека, способного оценить это профессионально, решение принимается на основе того, кто увереннее говорил на встрече — а не того, кто прав.
Три конкретных исхода, которые повторяются чаще всего: выбран стек, который команда через год не может ни поддерживать, ни расширять найм на нём; нанят разработчик, чей реальный уровень никто не смог оценить на собеседовании; инвестору обещан срок, который был технически невыполним с самого начала.
Три точки, где это нужнее всего
| Стадия | Что решается |
|---|---|
| До первого разработчика | Выбор стека, реалистичная оценка стоимости первой версии, оценка первого коммерческого предложения |
| Команда есть, руководства нет | Код без ревью, архитектурные решения принимаются ситуативно, никто не отвечает за качество перед фаундером |
| Разговор с инвесторами | Технический due diligence, ответы на вопросы о масштабируемости и рисках |
Что реально входит в частичную занятость
Типичный объём — 15–25 часов в месяц. Внутри этого времени: техническая стратегия и архитектурные решения на развилках, участие в найме (составление вакансий на техническом языке, отражающем реальные требования, оценка кандидатов на интервью), периодическое код-ревью — не построчная проверка каждого коммита, а взгляд со стороны раз в две-четыре недели, который ловит проблемы до того, как они станут дорогими, и подготовка технической части материалов для инвесторов.
Формат честно не покрывает: ежедневное написание кода в продукте (это штатный разработчик или тимлид) и мгновенную доступность в течение часов (это признак того, что нужен штатный технический руководитель, а не консультант на частичной занятости). Хороший фрактальный CTO скажет об этом прямо на первой встрече, а не будет обещать больше, чем формат реально позволяет.
Три формата и когда какой уместен
Полная занятость — когда компания достаточно велика и стабильна, чтобы обосновать полную ставку и опцион, и решения нужны в реальном времени каждый день. Частичная занятость — самый распространённый формат для стадии от идеи до series A: регулярное, но не постоянное вовлечение, которое масштабируется с ростом компании. По запросу (advisory) — минимальный формат для компаний, которым нужна редкая, но экспертная сверка решений, без регулярной вовлечённости в операционную работу.
Как отличить хорошего кандидата от плохого
Красный флаг номер один — расплывчатость про часы и доступность: хороший фрактальный CTO с самого начала фиксирует конкретное число часов и формат связи, а не отвечает «будем на связи по мере необходимости». Красный флаг номер два — отсутствие внятного процесса код-ревью: если кандидат не может объяснить, как именно он будет проверять чужой код и с какой периодичностью, скорее всего, этого не будет происходить на практике.
Хороший тест на собеседовании — попросить кандидата разобрать реальный архитектурный компромисс из своего прошлого опыта: что выбрали, почему, и что оказалось не так, как ожидалось. Кандидат, который может честно рассказать о неидеальном решении и его последствиях, обычно надёжнее того, кто рассказывает только истории успеха без единой ошибки.
Естественная точка перехода к штатному найму
Формат не рассчитан на бесконечность. Естественный момент перехода к штатному техническому директору — когда объём решений, требующих технического голоса, регулярно превышает согласованные часы, или когда компания достигает стадии, на которой полная ставка и опцион экономически оправданы. Хороший фрактальный CTO не держится за клиента вечно — он честно говорит о приближении этой точки и часто помогает нанять себе замену, потому что это тоже входит в задачу технического руководства, а не противоречит ей.
Частые вопросы
Нужен ли CTO на аутсорс на самой ранней стадии стартапа?
Часто да, именно ДО найма первого разработчика — это одна из трёх точек, где технический голос нужнее всего. На этой стадии решается выбор стека и реалистичная оценка стоимости первой версии продукта, и ошибка здесь стоит дороже, чем на любой последующей стадии, потому что закладывает фундамент, который потом сложно поменять.
Сколько часов в месяц обычно занимает CTO на аутсорс?
Типичный диапазон — 15–25 часов в месяц: регулярные созвоны с фаундером, периодическое код-ревью, участие в найме и архитектурные решения по мере возникновения вопросов. Объём растёт, если требуется более плотное вовлечение — например, активный найм команды или подготовка к раунду инвестиций, — и это стоит обсуждать заранее, а не постфактум.
Чем хороший фрактальный CTO отличается от плохого?
Хороший кандидат с самого начала фиксирует конкретное число часов и формат доступности, а не говорит расплывчато «будем на связи». У него есть чёткий, объяснимый процесс код-ревью. И он может честно разобрать неидеальное архитектурное решение из своего прошлого опыта, а не только истории успеха. Расплывчатость по этим трём пунктам на собеседовании — надёжный повод насторожиться.
Когда пора переходить от CTO на аутсорс к штатному найму?
Когда объём решений, требующих технического голоса, регулярно превышает согласованные часы, или когда компания достигает стадии, на которой полная ставка и опцион экономически оправданы масштабом. Хороший фрактальный CTO сам обозначит приближение этой точки и часто помогает найти и нанять постоянную замену — это естественное продолжение его роли, а не признак того, что формат провалился.
Нужна помощь с этой задачей?
Мы делаем это на практике, а не только пишем об этом. Опишите задачу — разберём и пришлём смету по этапам.
Услуги по теме
- CTO на аутсорсСтартапу на ранней стадии часто не по карману штатный технический директор, но без технического голоса в решениях компания рискует выбрать не тот стек, нанять не тех людей или неверно представить продукт инвестору. CTO на аутсорс закрывает эту роль на частичной занятости — ровно в том объёме, который нужен сейчас.
- IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.
- Разработка веб-приложений и Telegram Mini AppКогда сайта уже мало и нужен продукт: личный кабинет, дашборд, внутренний сервис или Mini App внутри Telegram. Проектируем архитектуру, пишем бэкенд и фронтенд, доводим до релиза.
Читать дальше
- Технический due diligence перед инвестициями или покупкой бизнесаRed flag в кодовой базе не всегда убивает сделку — чаще он меняет цену, эскроу или обязательства после закрытия. Разбираем, что проверяется и почему спешка под давлением сроков сделки вредит именно находкам.
- Как выбрать стек технологий для проекта: критерии, а не модаСтек выбирают на 3–5 лет вперёд, а решают за один созвон. Разбираем, в каком порядке принимать решения, какие критерии реально имеют вес, какие стеки работают для шести типов проектов и сколько стоит ошибка.
- Как выбрать подрядчика на разработку: чек-лист вопросов и красные флагиПрактическое руководство по выбору подрядчика: кому подходит фрилансер, а кому интегратор, какие 25 вопросов задать на первом созвоне, как проверить кейсы в портфолио и что обязательно должно быть в договоре.