Порог расходов AI-компании: что всё равно стоит денег после сокращений

Почему расходы не падают почти до нуля

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

Порог снижается. Он не исчезает.

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

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

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

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

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

Где заканчивается экономия на зарплатах

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

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

Именно здесь скрывается реальная стоимость. Строка зарплат становится меньше, но труд не исчезает. Он переходит к людям, у которых и так нет свободного времени. Если фаундер тратит 12 часов в неделю на проверку pull request, исправление промптов и разбор проблем в продакшене, эти часы тоже должны быть в операционном бюджете.

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

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

Когда это происходит, одни и те же сценарии повторяются снова и снова:

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

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

Счета, которые остаются каждый месяц

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

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

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

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

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

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

Простое приложение может жить бережливо. Но бесплатно оно не работает.

Почему проверки всё равно стоят денег

AI может быстро писать код. Но он не может взять на себя ответственность за релиз.

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

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

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

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

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

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

Как оценить свой порог

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

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

Затем добавьте человеческий слой. Посчитайте реальные часы на ревью кода, проверки безопасности, наблюдение за продакшеном, разбор обращений в поддержку и все странные случаи, которые автоматизация пропускает. Если ревью занимает 12 часов в неделю, работа по безопасности — 4, а разбор обращений — 6, оцените эти часы по той ставке, которую вы действительно заплатили бы.

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

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

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

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

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

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

Обычный месяц может выглядеть так:

• Хостинг в облаке для приложения, API, базы данных и staging: около $1,200
• Вызовы моделей для помощи с кодом, черновиков ответов и внутренних задач: около $900
• Логи, отслеживание ошибок и метрики: около $350
• Бэкапы и хранилище: около $250

Это примерно $2,700 без учёта времени на проверки.

Теперь добавим работу людей. Если команда выпускает релиз раз в неделю и каждый человек тратит около трёх часов на проверки и контроль релиза, это 24 часа в месяц. Если поставить простую ставку $60 в час, вы добавите $1,440. Реальный месячный порог теперь ближе к $4,100.

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

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

Вот в чём смысл. Маленькая AI-first компания может жить намного бережливее, чем старый софтверный отдел. Но у неё всё равно есть порог, и один тяжёлый месяц может перечеркнуть экономию спокойного.

Ошибки, которые скрывают настоящий порог

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

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

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

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

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

Годовые продления прячутся на виду. Как и минимальные контракты. Продления доменов, минимальные тарифы мониторинга, инструменты безопасности, support-планы и зарезервированные места часто бьют сильнее, чем ожидается, потому что команды считают только то, что заплатили в этом месяце.

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

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

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

Короткий стресс-тест очень помогает:

• Может ли один человек достаточно быстро проверять каждое изменение в продакшене, не превращая релизы в узкое место?
• Сможет ли кто-то восстановить бэкап за прошлую неделю, не гадая, куда его разворачивать и сколько это займёт?
• Замечает ли команда сбои входа, проблемы с оплатой или таймауты API раньше клиентов?
• Что будет, если использование моделей на несколько дней удвоится?
• Может ли кто-то объяснить каждый повторяющийся счёт простыми словами?

Эти проверки базовые. И они работают.

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

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

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

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

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

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

Если хотите второе мнение, Олег Сотников занимается такой работой в формате Fractional CTO через oleg.is. Он помогает стартапам и небольшим компаниям с бережливой инфраструктурой, AI-first подходами к разработке и процессами проверки, которые помогают держать расходы под контролем, не делая продукт хрупким.

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