Цены fractional CTO: ретейнеры, fees и ловушки бонусов

Почему модель оплаты имеет значение

Модель оплаты не просто задает бюджет. Она формирует поведение.

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

Фиксированный ежемесячный ретейнер дает advisor повод быть ближе к бизнесу, отвечать на мелкие вопросы и останавливать плохие решения до того, как они станут дорогими. Это часто укрепляет доверие, потому что каждый звонок не превращается в новый счет. Но слабый ретейнер может размыть границы scope. Основатели начинают просить «еще вот это», а advisor начинает беречь время.

Оплата за проект тянет ситуацию в другую сторону. Она вознаграждает понятную точку финиша: провести аудит стека, нанять первых инженеров, спланировать миграцию на AI, сократить расходы на облако. Иногда это отлично работает. Но как только оплата зависит от результата, люди начинают защищать проект, а не компанию. Основатель может избегать смены курса, потому что это ломает смету. Advisor может предпочитать работу, которая подходит под statement of work, даже если умнее было бы остановиться.

Success bonuses создают самое острое напряжение. Если доплата зависит от привлечения инвестиций, даты запуска или экономии, обе стороны могут начать гнаться за цифрой и игнорировать хаос за ней. Быстрый запуск может победить безопасный запуск. «Экономия» может хорошо выглядеть на бумаге, пока накапливаются техдолг, нагрузка на поддержку или проблемы с наймом.

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

Именно поэтому pricing для fractional CTO — это никогда не только про цену. Он определяет, сможет ли ваш advisor сказать: «Сделайте меньше, поставьте этот найм на паузу, перепишите этот план», не споря с договором. Более чистые стимулы помогают получать честный совет именно тогда, когда компания в нем нуждается больше всего.

Что обычно покрывает ретейнер

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

Большинство ретейнеров покрывают скорее время на консультации, чем непосредственное выполнение работ. Обычно это регулярные плановые созвоны, ревью архитектуры, вклад в roadmap, обсуждение trade-off, интервью с кандидатами, проверка подрядчиков и короткая async-поддержка между встречами. Если основатель спрашивает: «Добавить эту фичу сейчас или сначала исправить data model?», это нормальная работа в рамках ретейнера.

Ручное выполнение работы лучше выносить в отдельную категорию. Написание production-кода, перестройка инфраструктуры, исправление сломанного деплоя, ежедневное управление инженерами или ведение sprint execution часто требуют отдельного объема и отдельной цены. Некоторые fractional CTO делают и то и другое, но в договоре нужно простыми словами разделить консультации и выполнение работ. Иначе клиент может ждать builder-а, а advisor будет думать, что его наняли, чтобы направлять команду.

Типичный ретейнер может включать один-два регулярных созвона в неделю или в месяц, ревью продуктовых и технических решений, ограниченные вопросы в email или чате, а также легкий контроль найма, оценок или архитектуры. Эти детали важнее, чем многие основатели ожидают.

Скорость ответа быстро влияет на цену. Ретейнер с ответом в течение двух рабочих дней стоит дешевле, чем доступ в Slack в тот же день. Нагрузка на встречи тоже важна. Один дополнительный стратегический созвон часто создает часы последующей работы, потому что кому-то все равно нужно прочитать документы, проверить tickets и зафиксировать решения.

Эта модель лучше всего подходит, когда продуктовые решения продолжают меняться. Стартапы на ранней стадии часто нуждаются в стабильном участии в вопросах scope, найма, архитектуры, внедрения AI или выбора инфраструктуры, но им не нужен CTO на полный день. В таком случае ретейнер дает регулярный доступ к зрелой оценке без оплаты полноценной executive-позиции.

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

Как работают project fees

Project fee означает, что обе стороны заранее договариваются о конкретной задаче и фиксированной цене до начала работ. Это может быть аудит архитектуры, настройка AI development workflow или план по сокращению расходов на облако. Если задача понятна, а финиш легко увидеть, модель проста для обеих сторон.

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

Фиксированная цена лучше всего работает, когда четыре вещи ясны: что будет поставлено, что должен предоставить клиент, когда происходят feedback и approvals, и что считается «готово». Если эти пункты расплывчаты, фиксированная цена перестает ощущаться фиксированной.

Обычно проблема возникает из-за изменения scope. Команда просит дополнительную проверку подрядчика, еще одно интервью с кандидатом или вторую версию roadmap. Каждая просьба по отдельности кажется маленькой. Вместе они могут удвоить объем работы. Тогда кому-то приходится выбирать: добавить неоплаченные часы, сократить глубину или заново открывать сделку.

Сроки тоже меняют отношения. На ретейнере advisor может думать вместе с командой и корректировать план от недели к неделе. На project fee важнее становится часы и дедлайн. Advisor начинает беречь время, добиваться решений и говорить «нет» побочным просьбам. Это не проблема характера. Именно так фиксированная цена остается рабочей.

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

Project-based CTO fees хорошо подходят для ограниченной по объему работы. Гораздо хуже — когда настоящая проблема становится видна только после начала проекта.

Где success bonus создает напряжение

Success bonus звучит справедливо. Если компания получает результат, внешний CTO получает дополнительную оплату. Частые примеры — бонус за запуск до выставки, снижение расходов на облако на 25% или прохождение технической проверки покупателя во время сделки M&A.

Такой формат лучше всего работает, когда результат ясен, срок разумный, а advisor может напрямую повлиять на итог. Бонус за снижение расходов на хостинг может иметь смысл, если uptime, response time и пределы по инцидентам остаются фиксированными. Тогда вознаграждается лучшая архитектура, а не слепое урезание затрат.

Проблемы начинаются, когда бонус смотрит не туда.

Бонусы, завязанные на выручку, создают больше всего напряжения. Выручка зависит от ценообразования, sales calls, спроса, сезонности и удачи. Fractional CTO может помочь с доставкой продукта, но не контролирует все это. Если бонус зависит от booked revenue, он может начать продвигать быструю доработку фич для сделок, которые вот-вот закроются, и игнорировать cleanup кода, покрытие тестами или просроченные security fix.

На один квартал это может выглядеть разумно. Через шесть месяцев команда может тратить вдвое больше времени на выпуск чего-то нового.

Цели по техническому качеству обычно чище, потому что они ближе к реальной работе advisor-а. Бонус, завязанный на меньшее число production incidents, успешную миграцию, более быструю доставку релизов или меньшие инфраструктурные расходы при стабильном uptime, легче защитить. Компания может проверить результат, а advisor может на него влиять.

Даже тогда узкие метрики могут искажать поведение. Если платить бонус за меньшее число багов, кто-то может просто начать реже их отмечать. Если платить за более быстрые релизы, кто-то может урезать тестирование. Бонусам нужны ограничения. Задайте baseline, опишите, как вы измеряете результат, и добавьте минимальные требования к качеству, uptime, безопасности и документации.

Небольшой пример стартапа делает это особенно понятным. Допустим, основатель предлагает бонус, если CTO поможет выйти на 100 000 долларов новой ежемесячной выручки. CTO может начать срочно делать кастомные фичи для одного крупного клиента. Более удачный вариант — бонус за выпуск self-serve onboarding flow к определенной дате с согласованными показателями надежности и конверсии. Это все еще поддерживает рост, но не поощряет shortcuts.

Если вы используете success bonus, делайте его узким, измеримым и привязанным к той работе, которой advisor действительно может управлять.

Простой пример для стартапа

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

Вот где pricing становится реальным. На бумаге работа выглядит одинаково, но модель оплаты меняет то, что происходит каждое утро во вторник.

При ежемесячном ретейнере внешний CTO действует как стабильный партнер. На первой неделе он смотрит roadmap и ужесточает план релизов. На второй неделе неудачный deploy ломает биллинг, и тогда он переключается на разбор инцидента, alerts и правила rollback. На третьей неделе основателю нужна помощь с интервью backend-кандидата, и CTO тратит полдня на найм. В этом и смысл гибкости. Проблема возникает, когда основатель продолжает добавлять задачи и ожидает внимания на полный день за оплату неполного.

При оплате за проект стартап покупает определенный результат, а не открытый по объему help. Внешний CTO может согласиться к концу месяца выдать более чистый процесс deployment, базовую observability и документ для передачи. Еженедельные решения становятся жестче. Если основатель просит помочь с наймом или хочет пересмотреть scope продукта, advisor может возразить, потому что эти часы съедают фиксированную задачу. Это может быть полезной дисциплиной. Но может и восприниматься холодно, когда команда сталкивается с реальной проблемой чуть за пределами согласованного scope.

При success bonus стимулы начинают смещаться. Допустим, стартап платит небольшой базовый fee и бонус, если он запускается вовремя или закрывает seed round. Тогда у внешнего CTO появляется причина поддерживать работу, которая хорошо выглядит в демо или investor update. Команда может отложить cleanup, тесты или внутренние инструменты, потому что эти задачи не двигают бонус. Если fundraising провалится по причинам, на которые ни один инженер не влияет, спор начнется очень быстро.

Для такой компании часто лучше подходит смешанная модель. Стартап может платить небольшой ретейнер за еженедельные решения, поддержку основателя и найм, а затем добавить фиксированную оплату за одну понятную задачу, например перестройку CI/CD и проверок релизов. Такое разделение дает команде пространство менять курс в течение недели, не превращая каждый сюрприз в спор о цене.

Как выбрать модель

Большинство основателей начинают с ставки. Обычно это ошибка. Начните с бизнес-проблемы, которую нужно решить в ближайшие 60–90 дней, потому что pricing имеет смысл только тогда, когда задача ясна.

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

1. Запишите результат, который вам нужен. Держите его конкретным. «Нанять двух инженеров», «сократить расходы на облако» или «выпустить первую платную версию» — это уже достаточно ясно, чтобы оценить цену.
2. Разделите работу на консультации и исполнение. Консультации обычно включают ревью roadmap, выбор архитектуры, помощь с наймом и еженедельные встречи с руководством. Исполнение включает практическую настройку, работу с инцидентами, изменение процессов и поставку конкретного проекта.
3. Поставьте рамки до разговора о деньгах. Решите, как часто вы будете смотреть прогресс, что входит в scope, что вызывает доплату и кто принимает финальное решение при разногласиях.
4. Выберите самый простой формат, который подходит задаче. Если работа в основном требует постоянной оценки, обычно подходит ретейнер. Если у задачи есть четкое начало и конец, проще project fee. Если нужно и то и другое, используйте небольшой hybrid вместо сложной схемы.

Точки проверки важны сильнее, чем многие команды ожидают. Короткая сверка каждые две или четыре недели помогает остановить расползание scope до того, как оно превратится в спор. Зафиксируйте в письме или договоре cadence встреч, время ответа и deliverables. Также укажите человека, который утверждает дополнительную работу. Если никто не владеет этим решением, все будут понимать его по-разному.

Небольшой стартап может попросить еженедельное ревью архитектуры продукта, помощь с интервью инженеров и исправление слабой CI/CD-схемы. Это не один тип работы. Небольшой ретейнер за еженедельное техническое лидерство плюс фиксированная сумма за cleanup CI/CD обычно проще, чем одна общая цена на все.

Если план ценообразования можно объяснить за десять минут, упростите его. Ясный scope, понятная ответственность и одна простая модель оплаты обычно лучше, чем хитрый договор.

Ошибки, которые создают трение

Большинство конфликтов вокруг цен для fractional CTO начинается еще до первого счета. Они начинаются тогда, когда обе стороны используют одни и те же слова для разных задач. «Стратегия», «поддержка» и «delivery» звучат понятно во время звонка, а потом становятся расплывчатыми, когда работа уже началась.

Ретейнер часто ломается, когда никто не задает cadence. Если основатель слышит «постоянный доступ», он может ожидать быстрых ответов, помощь в чате, дополнительные встречи и emergency input в авральные недели. Advisor может ожидать один еженедельный созвон, проверку документов и фиксированный лимит часов. Такое несовпадение быстро рождает раздражение.

Project fees создают другую проблему. Они подходят для работы с четкими границами, например системного аудита, плана миграции или пересборки процесса найма. Для открытой стратегии они подходят хуже. Если scope все время двигается, фиксированная цена перестает казаться справедливой одной из сторон.

Бонусы создают напряжение, когда они завязаны на vanity metrics. Загрузки, запросы на демо, шум в соцсетях и интерес инвесторов хорошо смотрятся на слайде, но технический advisor не контролирует их в одиночку. Как только деньги зависят от таких цифр, люди начинают спорить об attribution вместо того, чтобы улучшать продукт.

Еще одна частая ошибка — упаковывать очень разные цели в один пакет. Найм, архитектура и delivery требуют отдельного scope. Если все смешать, никто не поймет, что значит «готово».

Более чистое соглашение разделяет работу простым языком. Найм включает дизайн интервью, review кандидатов и финальные input по найму. Архитектура включает ревью системы, обсуждение рисков и технический план. Delivery включает milestones, проверки с командой и решения по релизу. Бизнес-результаты вроде сокращения затрат или готовности к запуску стоит включать в договор только тогда, когда контроль действительно разделен.

Простой пример показывает, почему это важно. Стартап платит ежемесячный ретейнер за «CTO support» и одновременно просит построить новый hiring pipeline, переписать архитектуру и назначить дату релиза версии два. К второму месяцу основатель считает, что advisor двигается слишком медленно. Advisor считает, что компания добавила три проекта по цене одного.

Решение скучное, поэтому оно и работает. Зафиксируйте cadence встреч, время ответа, лимиты по часам, ownership и то, что происходит при росте scope. Если у задачи нет четкого конца, не включайте ее в project fee. Если бонус зависит от маркетингового или sales-шума, уберите его.

Проверки перед подписанием

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

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

1. Определите, кто формирует повестку недели. Если основатель может менять приоритеты через день, advisor будет больше реагировать, чем решать реальные проблемы. Если повесткой управляет CTO, опишите, как он получает одобрение и за какое время основатель должен отвечать.
2. Запишите, что происходит, когда работа меняется. Проект, который начинается как ревью архитектуры, может превратиться в найм, звонки с подрядчиками, поддержку инцидентов или настройку AI-инструментов. Укажите, что остается внутри fee, что требует новой сметы и кто утверждает допработы до их начала.
3. Выберите метрики прогресса, которые подходят задаче. Часы сами по себе — слабый показатель. Лучше отслеживать такие результаты, как выпуск релиза, сокращение расходов на облако, закрытый инженерный найм, снижение числа инцидентов или превращение расплывчатых идей продукта в понятный план.
4. Заранее определите правила выхода. Если одна из сторон хочет прекратить работу, договор должен говорить, сколько дается notice, что происходит с незавершенной работой и когда должны быть завершены доступы, документы и передача дел.

Одна маленькая деталь сильно снижает стресс: назовите человека, который принимает финальные решения. Во многих стартапах у всех есть мнение о продукте, найме и технологиях. Если три человека могут менять направление для внешнего CTO, pricing перестает что-то значить, потому что объем работы постоянно плывет.

Осторожно относитесь к размытым формулировкам вроде «strategic support as needed» или «reasonable assistance during launch». Эти фразы кажутся безобидными, но потом создают споры. Замените их цифрами, примерами и лимитами.

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

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

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

Выберите модель оплаты, которая соответствует задаче перед вами. Ретейнер лучше всего подходит, когда нужна стабильная внешняя поддержка: помощь с наймом, решения по roadmap, ревью подрядчиков, техническое планирование и регулярный доступ к человеку, который помогает основателю принимать решения неделя за неделей. Project fee подходит для узкой задачи с понятным финишем, например для аудита архитектуры, пересмотра расходов на облако или спасения delivery. Success bonus подходит только тогда, когда результат легко измерить и обе стороны могут честно на него влиять.

Большинству стартапов не стоит подписывать длинное соглашение в первый же день. Trial на 30–60 дней дает обеим сторонам достаточно времени, чтобы проверить общение, темп и качество решений. Вы быстро увидите, задает ли advisor точные вопросы, замечает ли риски заранее и помогает ли команде двигаться вперед.

Запишите стимулы простым языком до того, как кто-то подпишет договор. Пропустите расплывчатые формулировки вроде «бонус за рост» или «оплата, завязанная на успех запуска». Укажите trigger, кто им управляет, когда вы его измеряете и что происходит, если компания меняет курс. Если advisor может повысить свой upside, просто добавив больше работы или растянув scope, ограничьте это сразу.

Помогает простой фильтр. Используйте ретейнер для постоянного лидерства и регулярной поддержки основателя. Используйте project fee для фиксированного scope с конкретным результатом. Используйте success bonus только для узкой цели, которую обе стороны могут проверить.

Когда сравниваете pricing для fractional CTO, не останавливайтесь на месячной цифре. Посмотрите, какое поведение поощряет модель. Дешевый fee может обойтись дороже позже, если он подталкивает к поспешным запускам, лишним зависимостям или бесконечным изменениям scope.

Если перед решением вам нужен внешний взгляд, Oleg Sotnikov на oleg.is предлагает услуги fractional CTO и startup advisory. Он руководил стартапами и крупными техническими командами и часто помогает основателям разобраться со scope, инфраструктурой и компромиссами по затратам еще до того, как эти вопросы превращаются в спор о договоре.

Короткий trial, ясный scope и простой язык вокруг стимулов дадут для доверия больше, чем отшлифованный договор, полный расплывчатых обещаний.