Агентство, подрядчик или фракционный CTO: что подходит и когда

Почему этот выбор быстро становится сложным

Агентство, подрядчик и фракционный CTO — все они могут помочь с разработкой ПО, но делают разные вещи.

Агентство продаёт поставку. Подрядчик продаёт человеческую работу. Внешнее техническое руководство продаёт суждение, приоритеты и ответственность.

Это кажется очевидным, пока компания не окажется под давлением. Основатель хочет что‑то выпустить, слышит похожие цены и думает, что варианты схожи. Обычно это не так.

Цена проявляется позже, а не в начале. Одно предложение может выглядеть дешевле, но задержки, переделки, неясные спецификации и грязные передачи быстро съедают экономию. Проект, который сдвигается на шесть недель, часто стоит дороже, чем разница между изначальными предложениями.

Одна из самых распространённых ошибок — покупать исполнение, когда настоящая проблема — направление. Если никто не решил, что строить первым, какой уровень качества приемлем или какие сокращения безопасны, добавление разработчиков почти ничего не решит. Это просто распространяет путаницу.

Представьте небольшую стартап‑команду: один основатель и двое разработчиков. Основатель нанимает подрядчика, чтобы ускориться, но роадмап постоянно меняется, и никто не принимает окончательных решений по объёму. Подрядчик кодит, команда вносит правки, а дата релиза отъезжает — потому что никто не владеет общей картиной.

Команды также тормозят, когда ответственность распределена неправильно. Один пишет задачи, другой ревьюит код, кто‑то утверждает дедлайны — и никто не отвечает за результат. Когда объём растёт, баги накапливаются, оценки срываются, и каждый может ссылаться на кого‑то другого.

Вот почему выбор сложнее, чем кажется. Вы выбираете, кто будет выполнять работу, но также выбираете, кто определяет работу, кто защищает качество и кто скажет «нет, это не в объёме», пока бюджет не закончился.

Что на самом деле означают эти варианты

Проще всего разделять варианты по ответственности. Кто владеет планом, кто выполняет работу и кто принимает тяжёлые решения при изменении объёма? Ответ обычно подсказывает, нужно ли вам агентство, подрядчик или внешнее техническое руководство.

Агентство даёт команду по одному контракту. Вы не нанимаете одного человека — вы покупаете дизайн, разработку, управление проектом и отлаженный процесс. Это хорошо, когда нужны несколько навыков сразу и вы хотите, чтобы один контрагент отвечал за поставку. Цена — это некоторое отдаление. Если вы плохо управляете объёмом, команда может много работать, но двигать продукт в неверном направлении.

Подрядчик — это один человек, продающий время и навык. Вы берёте подрядчика, когда уже точно знаете, что нужно сделать, или когда кто‑то внутри компании может чётко прописать задачи и проверить работу. Подрядчики часто стартуют быстро и стоят дешевле агентства. Их легко неправильно использовать: если никто не расставляет приоритеты, даже сильный подрядчик будет действовать наугад.

Внешнее техническое руководство решает другой набор задач. Этот человек обычно не заменяет команду разработчиков. Он задаёт направление, ревьюит планы и код, ставит под сомнение оценки и помогает бизнесу принимать разумные продуктовые и инженерные решения. Фракционный CTO часто выполняет такую роль. Они связывают основателей, продуктовые решения, найм, архитектуру и доставку, чтобы всё держалось вместе.

Проще говоря: агентство добавляет мощность исполнения. Подрядчик добавляет отдельный навык. Фракционный CTO добавляет суждение и надзор. Некоторым компаниям нужен лишь один из этих вариантов. Многим нужны два одновременно, особенно когда основатели умеют описать продукт, но ещё не готовы управлять технической командой.

Когда агентство работает хорошо

Агентство имеет смысл, когда работе нужны сразу несколько навыков. Если нужны дизайн, разработка, тестирование и релиз в рамках одного проекта, одно агентство закроет это быстрее, чем поочерёдный найм специалистов. Вы получаете один контракт, один план и команду, которая уже умеет работать вместе.

Эта модель лучше всего работает, когда объём определён до старта. Редизайн продукта, клиентский портал или MVP с фиксированной датой — типичные примеры. Когда список фич, бюджет и сроки известны, агентство может назначить нужных людей и двигаться с меньшим трением.

Также это удобно, если вы хотите одного вендора вместо управления множеством фрилансеров. Отдельные наймы могут выглядеть дешевле в отчётах, но съедают время основателя. Агентство обычно стоит дороже одного подрядчика, но экономит часы координации каждую неделю.

Тем не менее агентствам нужна направляющая сторона. Кто‑то внутри вашей компании должен еженедельно проверять прогресс, отвечать на открытые вопросы и быстро утверждать изменения. Иначе команда может продолжать строить, а проект уйдёт в сторону от того, что вы на самом деле хотели.

Подходящее агентство обычно встречает четыре условия: определённый объём, бюджет установлен до старта, реальная необходимость в нескольких ролях сразу и кто‑то с вашей стороны, кто может еженедельно проверять работу.

Простой пример: стартапу нужен отполированный продукт за 12 недель для демо инвесторам и ранних пользователей. Экраны известны, бюджет утверждён, основатель может участвовать в еженедельных обзорах. Это чаще задача для агентства, чем для одиночного подрядчика.

Когда подрядчик работает хорошо

Подрядчик подходит, когда вы уже знаете задачу и нужен кто‑то, кто сделает её качественно. Работа должна быть узкой: её можно описать в несколько страниц, прикинуть с приемлемой точностью и еженедельно проверять.

Это хорошая схема, когда какая‑то часть продукта требует сосредоточенного внимания. Может быть, нужна мобильная оплата, новая админ‑страница, чистка базы данных или помощь с ускорением конвейера деплоя. Остальное остаётся с вашей командой.

Подрядчик также уместен, если у компании уже есть кто‑то, кто может быстро принимать решения. Этот человек не обязан писать код, но он должен отвечать на вопросы ежедневно, снимать блоки и принимать решения без задержек. Если внутри нет владельца работы, даже отличный подрядчик пойдёт в сторону.

Лучшие сценарии с подрядчиком имеют чёткий объём, внутреннюю команду, которая владеет роадмапом и приоритетами, одного менеджера для быстрых ответов и краткосрочную потребность в дополнительных руках вместо полного delivery team.

Часто это самый недорогой способ добавить мощность на короткий период. Вы платите за исполнение, а не за команду, аккаунт‑менеджмент или внешнее руководство, которое вам не нужно.

Типичный случай: у стартапа есть продукт‑лид и двое инженеров, и нужен ещё один человек, чтобы выпустить AI‑поиск до релиза. Подрядчик может взять эту фичу, работать в существующей кодовой базе и передать её команде.

Подрядчики плохо подходят, когда бриф расплывчат, приоритеты меняются каждые несколько дней или компания ожидает, что подрядчик сам разберётся с продуктовым направлением. Именно тут выбор чаще всего рушится.

Когда работает внешнее техническое руководство

Внешнее техническое руководство подходит, когда компании ещё не нужно больше кода. Ей нужны лучшие решения.

Если роадмап постоянно меняется, оценки регулярно срываются и никто не может сказать, что должно идти первым, фракционный CTO часто поможет больше, чем ещё один разработчик. То же верно, когда основатели слышат технические аргументы, которые сами не могут проверить. Вендор говорит одно, подрядчик — другое, и оба уверены в себе. Внешний технический лидер переводит компромиссы простым языком, оспаривает слабые оценки и объясняет, что рискованно, пустая трата или стоит отложить.

Этот вариант также подходит, когда направление продукта, найм и доставка нуждаются в одном владельце, а полноценный CTO ещё рано. Кто‑то должен решить, что строить, кто должен это строить и как проверять работу. Без такого владельца команда остаётся занятой, а прогресс кажется скользким.

Часто окупается до начала масштабной разработки. Несколько недель на архитектуру, объём, найм и правила доставки могут сберечь месяцы переделок позже. Многие команды пропускают это: руководство обычно нужно до масштабирования.

Представьте стартап с приблизительной идеей продукта и двумя конкурирующими сметами. Одно агентство предлагает большой ребилд. Один подрядчик предлагает быстрый патч. Внешнее техническое руководство может определить минимальную жизнеспособную версию, проверить, насколько реалистичны оценки, и задать путь, по которому команда реально пойдет.

Если вы хотите принимать более обоснованные решения до вложения значительных денег, этот вариант часто быстро окупается.

Кто должен управлять настройкой

Кто‑то внутри компании должен иметь чёткий контроль. В небольшой компании это обычно основатель. В чуть более крупной — продукт‑лид. Этот человек владеет целями, бюджетом и компромиссами и принимает окончательное решение, когда скорость, объём и качество тянут в разные стороны.

Если эту работу делят двое‑трое, всё быстро становиться грязным. Один настаивает на скорости, другой — на фичах, третий — на экономии. Команда получает смешанные сигналы и никто не отвечает за результат.

Агентство может управлять своими дизайнерами, разработчиками и менеджером проекта, но ему всё равно нужен один человек с вашей стороны для решений. Этот человек утверждает работу, отвечает на вопросы и держит агентство в рамках реальной бизнес‑цели. Иначе агентство начинает следовать за самым громким комментарием, а не за правильным приоритетом.

Подрядчику нужно ещё более плотное управление. Большинство подрядчиков работают лучше всего с быстрым фидбеком, ясным бэклогом и одним человеком, который следит за прогрессом изо дня в день. Если ревью занимают неделю или требования постоянно меняются, даже сильный подрядчик будет ждать или делать догадки, которые приведут к переделкам.

Внешнее техническое руководство должно сидеть близко к основателю. Если вы привлекаете фракционного CTO или внешнего технического лидера, не прячьте его под процессами вендора. Его задача — оценивать технические решения, оспаривать оценки и защищать компанию от плохих ускоренных решений.

Разделение простое: основатель или продукт‑лид владеют целями, бюджетом и компромиссами. Контакт в агентстве владеет утверждениями и бизнес‑контекстом. Менеджер подрядчика владеет ежедневным направлением и быстрыми ответами. Внешний технический лидер владеет техническим суждением и надзором за вендорами.

Держите ответственность чистой. Как только её начинают делить, мелкие решения превращаются в задержки, переделки и перекладывание вины.

Как выбирать шаг за шагом

Начните с результата, а не с модели найма. Если вы не можете описать результат одним простым предложением, вы ещё не готовы выбирать между агентством, подрядчиком или внешним техлидом.

Напишите это предложение так, как будто объясняете занятому коллеге. «Запустить клиентский портал за 10 недель» — понятно. «Улучшить нашу технологию» — нет.

Затем зафиксируйте известные факты. Объём, дедлайн, бюджет и один владелец — всё это должно быть записано. Если чего‑то не хватает, настройка становится шаткой, потому что никто не знает, кто может сказать «да», «нет» или «не сейчас».

Дальше выбор обычно проясняется. Если работа узкая и хорошо определена — подрядчик подойдёт. Если нужны дизайн, разработка, тестирование и управление проектом одновременно — чаще всего имеет смысл агентство. Если план расплывчат, команде нужно направление или вендорам нужен надзор — сначала лучше взять внешнее техническое руководство. А если нужны и доставка, и надзор, разделите роли сознательно. Не рассчитывайте, что подрядчик или агентство будут самоконтролироваться.

Количество необходимых ролей важнее, чем многие думают. Мобильное приложение, бэкенд, аналитика и проверка безопасности одновременно редко по силам одному человеку. Небольшой API‑фикс или короткий аудит — часто по силам.

Не начинайте с шестимесячного обязательства, если работа ещё нестабильна. Начните с маленькой вехи, которая покажет, как команда коммуницирует, оценивает, документирует и справляется с неожиданностями. Этот ранний тест сэкономит недели уборки позже.

Именно тут фракционный CTO может помочь до старта разработки. Он превратит расплывчатую цель в короткий план, установит первую веху и поможет не нанять не ту помощь.

Простой пример

Представьте небольшой SaaS с понятной бизнес‑проблемой. Клиентам нужен портал для отслеживания заказов и обновления платёжных данных. Команде также нужны две внутренние автоматизации: для передачи поддержки и для напоминаний по инвойсам. Основатель понимает, зачем это нужно, но не умеет ещё превращать это в экраны, рабочие процессы, приоритеты и последовательность разработки.

Если основатель нанимает одного подрядчика, работа может быстро стартовать. В первую неделю подрядчик может набросать портал, настроить логин и выпустить раннюю версию. Потом прогресс часто замедляется: кому‑то нужно ответить на базовые продуктовые вопросы — кто какие права получает, что происходит, если платёжные данные не совпадают с CRM, какая автоматизация важнее. Хороший подрядчик умеет строить, но обычно не должен придумывать весь план.

Агентство может справиться, если объём остаётся чётким. Если компания может сказать: «Постройте этот портал с этими полями, этим потоком согласований и этими тремя отчётами», то агентство сможет оценить и доставить работу. Проблема возникает, когда основатель продолжает менять приоритеты в середине проекта или добавляет расплывчатые просьбы вроде «сделайте поддержку умнее» без чётких правил.

Фракционный CTO меняет форму проекта ещё до старта кода. Он превращает идею основателя в план разработки, разбивает работу на фазы, проверяет оценки агентства или подрядчика и ловит пропущенные решения на раннем этапе. Они также могут еженедельно проверять результаты, чтобы компания не обнаружила базовые ошибки в самом конце.

В такой схеме нет нужды выбирать один путь навсегда. Фракционный CTO описывает работу, подрядчик берёт фокусную фичу, а агентство реализует чётко очерченный модуль. Такая смесь часто лучше, чем попытка заставить одного человека или команду угадать весь продукт.

Что обычно идёт не так

Большинство ошибок начинается с одной неверной ставки: основатель выбирает самое дешёвое решение для самой сложной проблемы.

Подрядчика просят одновременно решать продуктовую стратегию, доставку, найм и архитектуру. Агентство нанимают, чтобы быстро двигаться по продукту, который никто не описал. Внешнего техлида привлекают после месяцев дрейфа, а затем используют как советника без реальных полномочий.

Ещё более распространённая проблема — начало работ до согласования объёма, ответственности и процесса принятия решений. Первая неделя кажется продуктивной, вторая расплывчатой, а к третьей все спорят о том, что они думали, что купили.

Агентств часто обвиняют в медлительности, хотя на самом деле тормозит клиент. Клиент отвечает на продуктовый вопрос четыре дня, меняет приоритеты в спринте или даёт обратную связь через трёх человек. Быстрое агентство не спасёт медленного клиента.

Подрядчики сталкиваются с другой стеной. Они умеют строить и выпускать, но не должны самим придумывать бизнес. Если никто не отвечает на продуктовые вопросы, подрядчик либо ждёт, либо делает предположения. Ожидание тратит время. Предположения порождают переделки.

Внешнее техническое руководство терпит неудачу более тихо. Компания нанимает человека для направления, но не даёт ему полномочий устанавливать приоритеты, останавливать плохие идеи или говорить «нет» поспешным решениям. Тогда он превращается в протоколиста с громким титулом.

Несколько простых проверок предотвращают большинство проблем. Соотнесите проблему с уровнем помощи, которой вы нуждаетесь. Назначьте одного человека владельцем продуктовых решений. Решите, кто утверждает изменения объёма. Установите время ответа до старта работ. Если берёте внешнее руководство, дайте ему реальные полномочия или не берите никого вовсе.

Именно здесь опыт имеет значение. Кто‑то вроде Oleg Sotnikov, через oleg.is, работает как фракционный CTO и консультант стартапов — это бывает полезно, когда компании нужно техническое суждение по продукту, архитектуре, найму и контролю поставщиков, а не просто дополни́тельное кодирование.

Быстрые проверки перед подписанием

Множество плохих наймов выглядят хорошо на бумаге. Проблемы начинаются, когда никто не отвечает за маленькие, скучные решения, которые двигают работу.

Перед подписанием зафиксируйте, кто решает, что значит «готово». Если никто не может сказать, как выглядит завершённая фича, лендинг или миграция, вы позже будете спорить, завершена ли работа. Короткая письменная нота об приёмке лучше длинной продающей презентации.

Проверьте, как отвечают на продуктовые вопросы. Работа тормозит, когда разработчик или агентство ждут три дня ответа по крайним случаям, текстам, правилам ценообразования или ролям пользователей. Назначьте одного человека, который отвечает в течение дня. Если этот человек слишком занят, проект сдвинется.

Задайте прямые вопросы: кто утверждает результат перед оплатой? Кто отвечает на продуктовые и бизнес‑вопросы в рабочий день? Какой процесс ревью ловит слабый код, сломанные потоки или пропущенные детали? Что происходит, если объём меняется на второй неделе? Могут ли обе стороны остановиться после первой вехи без конфликта?

Контроль качества важнее, чем многие основатели ожидают. Если вы не можете сами проверить техническую работу, поручите это тому, кто может — внутреннему инженеру или внешнему техлиду. Фракционный CTO не должен сидеть в стороне и просто комментировать, если его задача — владеть ревью, оценкой рисков и компромиссами.

Ещё один момент: сделайте первую веху достаточно маленькой, чтобы проверить отношения. Две недели реальной работы скажут больше, чем шестимесячное обещание. Если команда пропускает базовую коммуникацию, избегает письменных изменений объёма или настаивает на полной предоплате — останавливайтесь.

Что делать дальше

Начните с самой маленькой вещи, которая убирает неопределённость. Не нужно решать всю кадровую стратегию в день обращения. Нужна только достаточная ясность, чтобы не платить не тому человеку за решение не той проблемы.

Если работа всё ещё расплывчата — купите направление, прежде чем покупать ещё код. Несколько сфокусированных сессий по определению продукта, сортировке приоритетов и назначению владельцев часто экономят недели переделок. Это обычно лучший первый шаг, когда люди расходятся во мнениях об объёме, дедлайнах или технических решениях.

Если объём уже стабилен — сопоставьте модель с задачей. Нанимайте подрядчика, когда задача узкая и у вас есть кто‑то, кто может управлять деталями. Берите агентство, когда нужно командное исполнение по определённому пакету работ. Подключайте внешнее техническое руководство, когда решения, приоритеты и структура команды ещё не готовы.

Держите первую привязку небольшой. Попробуйте короткую дискавери‑фазу, ограниченную разработку или понятный 30‑дневный план. Это даст реальные сигналы: как быстро принимаются решения, где сидят блокеры и готова ли работа к исполнению.

Короткая консультация может помочь. Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями по технической стратегии, архитектуре продукта и фракционной поддержке CTO — это подходит, если нужно оценить объём работ перед выбором поставщика или наймом.

Простой тест работает так: если вы можете описать результат, дедлайн и владельца в нескольких понятных предложениях — выбирайте модель доставки и действуйте. Если нет — сначала решите это. Чёткая ответственность побеждает дополнительные часы кодирования почти всегда.