Финансовая модель ИТ-продукта должна пережить задержку продаж: расходы на разработку идут раньше доходов

Что считать, если продукт ещё не продаётся? Начните с денег, доступных именно этому проекту, и дат платежей. Ожидаемые продажи в остаток не входят.

Срок окупаемости проекта считают по накопленному потоку с учётом всех выплат.

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

При монетизации нового продукта платную единицу отражают в функциях и доступах.

Точку безубыточности продукта считают по марже и постоянным расходам.

Правила P&L-отчёта задают распределение общего расхода между продуктами до разработки расчёта.

Отрицательный денежный поток ещё не означает кассовый разрыв. Запас пока покрывает платежи. Разрыв возникает, когда к дате платежа денег не хватает.

Анализ чувствительности проекта показывает, как меняется решение при изменении исходных допущений.

Что останется за пределами тарифа? Инфраструктура продукта, продажи и обслуживание. Нейросети разработки и ИИ-функции для клиентов оплачиваются по-разному.

На /services тариф «Один проект» стоит 250 000 ₽ в месяц на 7 октября 2026. Нейросети для кода, текстов и картинок включены.

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

В примере запас 1,6 млн ₽, платежи 400 тыс. ₽ в месяц. Суммы кроме тарифа условные. Налоги и возвраты своего проекта запишите отдельно по датам.

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

Наш опыт касается машины vibecoding.ru. На /open#cena 7 октября 2026 показана оценка ~540 880 ₽ за месяц инженера и подписок.

В эту оценку входят 500 000 ₽ за работу инженера. Инфраструктура считается отдельно. Оставить только подписки означало бы сделать работу инженера бесплатной.

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

Как проверить запас? Сначала разнесите плановые оплаты по месяцам. В примере первые деньги приходят в третьем месяце, а все расходы начинаются с первого.

Формула: остаток на начало плюс поступления минус платежи. Конец месяца становится началом следующего. Новое финансирование записывается отдельным поступлением.

При исходном плане минимальный остаток на конец месяца составляет 700 тыс. ₽. Это результат заданных чисел. Поступления здесь придуманы, они не подтверждают спрос.

Сдвиньте поступления на два месяца, сохранив платежи. Первые деньги приходят в пятом месяце. Разработка продолжается, запас расходуется.

Бюджет ИТ-проекта связывает полезные изменения с пределом ежемесячных расходов.

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

Прототип не назначает дату оплаты клиента. Готовность продукта планируют отдельно; срок работы разобран в статье о сроках разработки.

Когда менять заказ? До следующей оплаты. После второго месяца в примере есть версия и 800 тыс. ₽. Готовность версии условная, это не обещание срока.

С третьего месяца разработка на паузе, остальные платежи составляют 150 тыс. ₽ в месяц. В /services пауза переносит дни, деньги на счёт не возвращает.

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

Календарь пятого месяца вскрывает разрыв. 5-го надо заплатить 400 тыс. ₽, а 300 тыс. ₽ придут 25-го. До оплаты клиента не хватает 400 тыс. ₽.

В шестом месяце нехватка до поступления достигает 500 тыс. ₽, хотя итог месяца равен нулю. Поэтому добавить только 100 тыс. ₽ по месячной таблице недостаточно.

С паузой до поступлений остаётся минимум 350 тыс. ₽, выше выбранных 200 тыс. ₽ запаса. Срочные исправления оплачивают из бюджета обслуживания, пауза их не покрывает.

Анализ финансовой модели проекта начинается с выписки и календаря обязательств. Финансирование владельца или инвестора отмечайте отдельно от оплат покупателей.

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

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

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

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

1. Деньги нужны к дате платежа. Разнесите продажи и поступления по разным строкам.

2. Разработка составляет часть расходов. Добавьте инфраструктуру, продажи, обслуживание и обязательные платежи.

3. Задержку проверяют до заказа следующего месяца. Перенесите поступления и найдите минимальный остаток по датам.

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