Модель ценообразования fractional CTO для настройки, поддержки и AI

Почему одна фиксированная цена создаёт проблемы

Одна цена выглядит аккуратно на странице продаж, но часто смешивает в себе очень разные задачи. Именно здесь и начинаются проблемы с маржой. Модель ценообразования fractional CTO быстро ломается, когда discovery, настройка, поддержка и проверка AI сидят внутри одного фиксированного тарифа.

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

Стартап может попросить «помочь с настройкой AI-разработки», но под этим могут скрываться исправления CI/CD, правила доступа к моделям, тестирование промптов, схема code review, отслеживание ошибок и передача задач команде.

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

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

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

Чаще всего скрытая работа всплывает в одних и тех же местах: индивидуальная настройка, которая меняется от клиента к клиенту, запросы в поддержку после первого handoff, внутренняя проверка сгенерированных AI материалов и переделки из-за расплывчатого объёма работ.

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

Что на самом деле входит в настройку

В предложении настройка звучит как что-то небольшое. На практике она быстро разрастается.

Discovery-звонок часто начинается с простой цели, например: «настроить наш рабочий процесс» или «добавить проверку AI для команды». Через десять минут вы уже разбираете, кто утверждает изменения, где лежат спецификации, как перемещаются задачи, какие инструменты команда уже использует и где работа стопорится. Это не админка. Это консультационная работа.

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

Мелкие запросы тоже накапливаются. Один основатель просит новый вид доски. Другой хочет библиотеку промптов для code review. Потом кому-то нужно поменять роли пользователей, подправить форму и проверить ещё одну интеграцию. Каждый запрос выглядит незначительным. Но вместе они могут уничтожить целый день.

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

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

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

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

Как растёт нагрузка на поддержку

Большинство людей считают звонки, дорожную карту и запланированную разработку. Но маржа часто исчезает в другом месте: ответы в чате, разбор багов, статус-апдейты и короткие вопросы от основателя, которые прилетают между созвонами. Каждая такая задача кажется мелкой. Вместе они легко съедают несколько часов в неделю.

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

Пробуйте отслеживать поддержку маленькими единицами хотя бы две недели. Считайте такие вещи, как:

• ответы в чате и короткие созвоны
• разбор багов и проверка воспроизведения
• статус-апдейты для основателей, сотрудников или инвесторов
• незапланированные вопросы между встречами

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

Модель ценообразования fractional CTO, которая это игнорирует, на бумаге выглядит нормально, а в реальности — тонко. Может казаться, что вы продали четыре часа лидерства в неделю. На практике вы можете потратить ещё четыре на follow-up, переключение контекста и мелкие пожары.

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

Срочная помощь тоже должна иметь отдельную метку. Обычный follow-up может подождать до следующей проверки или окна ответа в тот же день. Срочная помощь ломает очередь. Производственные инциденты, сорванные релизы, вопросы безопасности и баги, которые видят клиенты, должны идти в отдельной категории с более высокой ценой или ограниченным месячным объёмом.

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

Почему проверка AI должна иметь отдельный бюджет

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

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

Написание промптов — это настоящая работа. Как и повторные прогоны.

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

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

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

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

Именно последнюю часть команды пропускают чаще всего. AI может написать аккуратный ответ, который всё равно сломает реальный процесс.

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

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

Когда проверка AI вынесена отдельной строкой в смете, клиенту видно, за что он платит. Это упрощает обсуждение объёма работ и спасает вас от бесплатной раздачи часов, которые не казались дорогими, пока не сложились вместе.

Как собрать коммерческое предложение

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

Пишите предложение слоями. Так настройка, поддержка и проверка AI остаются видимыми, и можно поменять одну часть, не ломая всю сделку.

1. Перечислите все задачи по настройке, которые ожидаются в первой фазе. Включите discovery-звонки, архитектурные решения, очистку репозитория, изменения CI/CD, настройку доступов, мониторинг, заметки для передачи дел и обучение основателя или команды.
2. Поставьте часы напротив каждой задачи. Если задача обычно разрастается, берите верхнюю границу вашего обычного диапазона.
3. Оцените месячную поддержку на основе похожих прошлых проектов. Считайте разбор багов, помощь с релизами, вопросы команды, звонки с вендорами и экстренные исправления.
4. Добавьте проверку AI отдельной строкой. Учтите и ваше время на проверку, и прямые расходы на использование моделей или связанных инструментов.
5. Задайте минимальную маржу ещё до отправки сметы. Если цифры опускаются ниже порога, сокращайте объём работ или поднимайте цену.

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

Стоимость проверки AI заслуживает такого же подхода. Если в поставке вы используете Claude, GPT или self-hosted модели, кому-то всё равно нужно читать результаты, ловить плохие предложения, перепроверять тесты и утверждать изменения. Счёт за модель важен, но во многих случаях ваше время на проверку важнее.

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

Простой пример из небольшой стартап-компании

Небольшой SaaS-стартап нанимает fractional CTO для двух задач, которые сначала кажутся скромными: помощь с онбордингом и советы по продукту. Основатели хотят, чтобы кто-то посмотрел на их стек, подчистил несколько слабых мест, подключился к планированию и помог команде использовать инструменты AI, чтобы выпускать быстрее.

Первое предложение — один месячный ретейнер. В него входят настройка, поддержка команды и общие CTO-советы, скажем, за $4,000 в месяц. На бумаге это выглядит просто. Стартапу нравится цена, потому что она кажется предсказуемой.

Потом начинается месяц.

Настройка занимает больше времени, чем ожидали. Кодовую базу нужно нормально проверить. В нескольких системах не хватает доступов. CI-пайплайн ломается на крайних случаях. Нужно привести в порядок шаги деплоя, базовую наблюдаемость и заметки для передачи дел, чтобы команда перестала полагаться на память. По отдельности это не выглядит огромным, но вместе съедает много часов.

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

Потом приходят расходы на проверку AI. Команда использует Claude или GPT, чтобы писать код, тесты и документацию. Это экономит время, но не убирает проверку. Кто-то всё равно должен проверить сгенерированный код, поймать слабые допущения, улучшить промпты и убедиться, что результат подходит продукту. До выхода первой фичи fractional CTO тратит ещё несколько часов на проверку AI-помощи.

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

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

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

Ошибки, которые фиксируют тонкую маржу

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

Ещё одна частая ошибка — назвать месячный ретейнер, не разобравшись в объёме настройки. Основатель может сказать, что ему нужна «поддержка CTO», но это может означать очень разные вещи. Одной компании нужен архитектурный обзор. Другой — очистка CI/CD, сокращение облачных расходов, помощь с наймом и план по AI-процессу. Это не одна и та же работа, и начинаться она не должна с одной и той же цифры.

Безлимитная поддержка звучит дружелюбно, но часто превращается в случайные сообщения в Slack, срочные просьбы о звонке и проверки по выходным, которые никто не посчитал. Поддержке нужны границы. Задайте окно ответа, каналы и месячный лимит, иначе ретейнер медленно превращается в on-call работу.

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

Одни и те же убийцы маржи всплывают снова и снова:

• бесплатный discovery, который превращается в техническую консультацию
• ретейнеры, проданные до оценки объёма настройки
• бесконечная поддержка без правил использования
• проверка AI, которую считают бонусом, а не оплачиваемой работой
• агентские цены, перенесённые на senior CTO-работу

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

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

Чек-лист перед публикацией цен

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

Прогоните цену через пять прямых вопросов:

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

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

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

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

Работа с AI нуждается в отдельном бюджете, даже если AI экономит время. Быстрая генерация всё равно создаёт работу по проверке. Кто-то должен проверить логику, безопасность, крайние случаи, тесты и то, соответствует ли результат продукту.

И последняя проверка — стресс-тест. Удвойте на бумаге входящий поток запросов. Если цена ломается, исправьте это до того, как клиент сделает это в реальности.

Что менять дальше

Сначала меняйте структуру, а потом уже цифру. Если одна цена покрывает discovery, настройку, поддержку и проверки AI, вы просто гадаете. И это гадание обычно становится дорогим, когда начинается настоящая работа.

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

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

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

Это важнее, чем думает большинство основателей. Первые клиенты часто просят «одно маленькое изменение» пять или шесть раз. С поэтапным предложением вы можете говорить «да», не давая проекту расползтись.

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

Если вам нужен второе мнение по ценообразованию для стартапа, архитектуре продукта или практическому внедрению AI, Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями в формате Fractional CTO advisory и AI-augmented development workflows. Такой внешний разбор помогает поймать слабые допущения до того, как они превратятся в привычку ценообразования.

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