Развёртывание продукта у заказчика: доходы, поддержка и риски

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

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

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

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

Потом начинается дрейф. Клиент A хочет SSO одним способом. Клиент B нуждается в другой версии базы. Клиент C запрещает исходящий доступ в интернет. После нескольких сделок ваше предложение по self‑host может разделиться на несколько версий одного и того же продукта.

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

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

Что покупатели обычно имеют в виду под self hosting

Когда покупатель спрашивает, можно ли разместить продукт у них, он может подразумевать три совсем разные вещи. Они могут хотеть on‑prem в собственном дата‑центре, приватный облачный аккаунт, которым управляете вы, или развёртывание внутри их собственной VPC в AWS или Google Cloud. На воронке продаж это звучит похоже, но меняет, кто отвечает за повседневную работу.

Некоторые говорят «self hosted SaaS», хотя на самом деле не хотят полного контроля. Им достаточно большей изоляции, чем в шаред‑окружении: отдельная база, фиксированный регион, приватный сетевой путь или выделенный кластер. Если не проговорить это, вы можете оценить дорогое развёртывание для проблемы, которую можно было решить проще.

Несколько практических вопросов обычно проясняют реальную просьбу. Где будет работать продукт: на их серверах, в их облачном аккаунте или в вашем управляемом окружении? Кто отвечает за бэкапы, хранение логов и мониторинг? Кто применяет патчи, вращает секреты и реагирует при сбоях? Что их служба безопасности требует перед запуском?

Последний вопрос важен ещё на ранней стадии. Одним компаниям достаточно стандартной анкеты по безопасности. Другие хотят архитектурную документацию, правила доступа, pentest или формальный ревью их команды безопасности. Фраза «self hosting» часто скрывает всё это.

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

Где реальный доход

Деньги реальные, когда self‑host решает проблему покупки, а не просто предпочтение. Некоторые организации готовы платить больше, потому что им нужен контроль над данными, сетевыми путями, правилами аудита или внутренними согласованиями. Команда, которая будет пользоваться вашим SaaS, может быть довольна, но те, кто подписывает контракт, — нет.

Тогда self‑hosted предложение открывает сделки, которые вы бы проиграли. Банк, фабрика или медицинская организация может отвергнуть шаред‑окружение по политике. Если ваш продукт запускается внутри их инфраструктуры, тот же покупатель может подписать гораздо более крупный контракт — у них снижается риск.

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

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

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

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

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

Поддержка усложняется в тот момент, когда каждый клиент работает в своём окружении. В обычной SaaS‑модели команда изучает одну среду и исправляет проблемы один раз. При self‑hosted установках каждый клиент добавляет новый набор правил сети, прокси, настроек хранилища, сертификатов, бэкапов и внутренних политик.

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

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

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

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

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

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

Почему обновления становятся узким местом

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

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

Старые установки создают вторую проблему. Инженеры перестают поддерживать одну текущую версию и начинают тянуть несколько старых одновременно. Это значит больше триажа багов, больше ветвлений в репозитории и постоянные вопросы: «На какой версии вы?» Команда может исправить баг в версии 8 и узнать, что три платящих клиента всё ещё на версии 6.

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

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

Хороший CI/CD снижает часть боли, но не убирает сомнения клиента. Поэтому политика обновлений важна до первой self‑hosted сделки, а не после неё.

Кто отвечает за ежедневную безопасность

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

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

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

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

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

Напишите границы поддержки простым языком. Скажите, что ваша команда расследует, что — клиент, и когда тикет превращается в security‑инцидент. Для self‑hosted SaaS эта линия важнее, чем многие думают. Если ваша команда поддерживает приложение, но не хост — скажите об этом прямо. Если вам нужен shell‑доступ для помощи, укажите это до закрытия сделки.

Практический способ принять решение

Некоторые запросы выглядят крупнее, чем есть на самом деле. Клиент просит self‑host, но на самом деле ему может понадобиться ускоренное security‑ревью, более жёсткий контроль данных или способ закрыть одну внутреннюю политику. Если вы будете трактовать каждый запрос как новую продуктовую линию, вы застрянете на месяцы лишней работы.

Начните с простого разделения запросов на корзины. Посмотрите, кто спрашивает, насколько велик контракт и как быстро нужен ответ. Крупный покупатель с ясным бюджетом отличается от маленькой команды, которая хочет self‑host только потому, что это «безопаснее».

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

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

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

Протестируйте предложение с одним‑двумя ранними клиентами, прежде чем анонсировать его широко. Следите за тем, что происходит после первой установки. Сколько часов потратила команда? Что ломалось? Нужен ли был постоянный hand‑holding? Эти ответы значат больше, чем сумма в контракте на первый день.

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

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

Средняя компания любит ваше приложение, но их IT‑команда не примет шаред‑сервис. Они хотят продукт в своей VPC. Также просят SSO, журналы аудита и согласование перед любым изменением в проде.

На бумаге это привлекательно. Ваш стандартный контракт — $18,000 в год. Они предлагают $65,000, если вы развернёте продукт у них. Звучит как явный плюс, пока не посчитаете работу вокруг софта.

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

Примерный первый год может выглядеть так:

• 3 недели инженерного времени на упаковку, SSO и журналы аудита
• 1 неделя DevOps для скриптов развёртывания и проверок окружения
• 10–15 часов основателя или продакта на переговоры, ревью и согласования
• Постоянная поддержка обновлений, сертификатов и проблем с доступом

Теперь прикиньте бюджет. Если эта работа стоит вам $35,000–$45,000, сделка стала гораздо менее прибыльной, чем казалось. Если клиент также ждёт быстрых ответов, помощи с апгрейдами или кастомных документов для внутренних аудитов, ваша прибыль может и вовсе исчезнуть.

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

Частые ошибки команд

Самая большая ошибка — сказать «да» слишком рано. Клиент просит self‑host, сделка кажется большой, и никто не определяет, что реально входит в поддержку.

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

Ценообразование — следующая ловушка. Команды берут одноразовую плату за работу, которая повторяется каждый квартал: апгрейды версий, ломающиеся интеграции, обновление сертификатов, проверки бэкапов и дрейф окружения.

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

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

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

Без ясного контракта по безопасности всё усложняется. Если клиент управляет серверами, кто патчит ОС, вращает секреты, смотрит логи и реагирует на инциденты?

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

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

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

Быстрая проверка перед «да»

Когда клиент просит self‑host, сделка может казаться больше, чем есть. Дополнительный доход привлекателен, но затраты на поддержку, трения обновлений и неясность по безопасности могут съесть выгоду быстрее, чем думают.

Пройдитесь по пяти проверкам перед согласием:

• Смотрите на первый год, а не на первый счёт. Оправдает ли себя сделка после звонков по установке, кастомной документации, багрепортов из необычных окружений и пары спас‑сессий?
• Спросите, можно ли один инсталлятор использовать для большинства будущих клиентов. Если каждый покупатель требует других скриптов, изменений в БД или особой облачной схемы, вы продаёте кастомную работу, а не стандартный продукт.
• Протестируйте путь обновления заранее. Если клиенты не могут перейти на следующую версию без помощи инженера, каждый релиз превратится в мини‑услугу.
• Напишите обязанности по безопасности на одной странице. Кто патчит серверы, вращает секреты, хранит бэкапы, смотрит логи и реагирует на инциденты? Если это трудно описать — ответственность неясна.
• Проверьте, подходит ли это компании, которую вы хотите строить. Команда, стремящаяся к чистому SaaS, может скатиться в enterprise‑услуги одна особая сделка за другой.

Одного «нет» не убьёт идею. Куча слабых «может быть» обычно должна.

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

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

Относитесь к первой сделке как к пилоту, а не как к постоянной продуктовой линии. Если клиент просит self‑host, сопротивляйтесь желанию обещать весь enterprise‑пакет с первого дня.

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

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

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

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

Если хотите внешнюю проверку прежде чем соглашаться, Oleg Sotnikov на oleg.is делает Fractional CTO‑работу. Небольшой аудит предложения, модели поддержки и инфраструктурного плана полезен до финального ценообразования, потому что исправление плохой self‑hosted сделки после запуска обычно стоит дороже, чем сказать «нет» сразу.