На конференции LDX3 инженерный лидер Nivia Henry обсудила, почему будущее SaaS не сводится к громким прогнозам о «смерти подписочных сервисов». Для IT-команд это практичный разговор: ИИ меняет экономику разработки, но не отменяет цену поддержки собственных систем, интеграций и инфраструктуры.
Запись беседы с Henry была сделана на площадке LDX3 — конференции LeadDev о техническом лидерстве, управлении и инженерной стратегии, сообщает Stack Overflow Blog. Henry недавно провела два с половиной года в Netflix, работая со сложными задачами в данных и инженерии, а до этого восемь лет занималась продуктовым развитием в Spotify. Поэтому спор «строить или покупать» она рассматривает не как выбор между идеологией и экономией, а как набор зависимостей, которые компания будет обслуживать годами.
Повод для дискуссии понятен. На фоне генеративного ИИ многие команды снова пересчитывают целесообразность облачных подписок: если модель может быстро написать интеграцию, интерфейс или внутренний сервис, то почему бы не заменить очередной внешний продукт собственным решением? Такой подход особенно соблазнителен, когда стоимость лицензий растёт, а поставщик навязывает пакеты функций, половина которых компании не нужна.
Но скорость первого прототипа почти ничего не говорит о полной стоимости владения. Самописный сервис нужно защищать, наблюдать, обновлять, масштабировать, документировать, встраивать в процессы доступа и поддерживать после ухода автора кода в другую команду. Внешний сервис тоже не бесплатен: он приносит зависимость от вендора, ограничения API, миграционные риски и регулярные платежи. Однако часть операционной работы уже включена в цену подписки — и именно эту часть легко потерять из расчёта, сравнивая месячный счёт за SaaS с затратами на разработчика в течение нескольких недель.
В эпоху ИИ калькулятор стал сложнее, а не проще. Инструменты генерации кода снижают порог входа для создания внутреннего продукта, но не избавляют от архитектурных решений. Модель может ускорить написание компонента, однако не определит за бизнес, где хранить данные, как разделить ответственность между системами, какие контракты выдержат нагрузку и сколько будет стоить ошибка в доступах. Чем критичнее процесс, тем меньше оснований принимать решение только по скорости демонстрации.
Отдельный акцент Henry делает на понимании архитектуры как условии контроля инфраструктурных расходов. Счёт за облако редко растёт из-за одного неверного выбора. Обычно его раздувают цепочки: дублирующиеся данные, лишние вызовы между сервисами, слишком дорогие уровни хранения, бесконтрольное масштабирование, неясные владельцы ресурсов. Без карты зависимостей команда видит конечную сумму, но не может уверенно объяснить, какой продукт, сервис или архитектурный компромисс её сформировал.
Для российских разработчиков и руководителей здесь нет экзотики: собственная разработка часто кажется вынужденным ответом на ограничения поставщиков и интеграционные барьеры. Но замена подписки внутренним проектом оправдана лишь тогда, когда компания готова владеть не только кодом, но и всей его жизнью. Полезнее сравнивать варианты по нескольким вопросам: насколько функция отличает бизнес от конкурентов, насколько критичны данные и надёжность, можно ли безопасно сменить поставщика и есть ли у команды ресурс на постоянную эксплуатацию.
Будущее SaaS, судя по этой логике, будет не про массовый отказ от готовых сервисов, а про более жёсткий отбор. ИИ способен сделать собственные инструменты дешевле на старте, но одновременно повышает цену архитектурной небрежности: когда создавать внутреннюю платформу становится проще, особенно важно не превратить её в ещё один бесхозный счёт за инфраструктуру.
