В бюджетах, которые мы видим у клиентов, IT чаще всего выглядит как одна строка с круглой суммой. Через полгода выясняется, что в неё не заложили ни поддержку, ни сервисы, ни продвижение — и проект превращается в источник неприятных сюрпризов для финансового директора.
Разложим по статьям, чтобы цифра в вашем бюджете выдержала встречу с реальностью.
01 · Почему одной цифры мало
Приложение — не покупка, а эксплуатация. Разработка занимает несколько недель, а живёт продукт годами, и расходы на эту жизнь не нулевые. Планировать нужно два разных блока: создание и владение.
Практическое правило: если в вашем бюджете есть только строка «разработка», значит вы заложили примерно две трети реальных годовых расходов.
02 · Шесть статей бюджета
03 · Первый год против второго
Первый год — это разработка плюс эксплуатация с момента релиза. Если релиз в середине года, эксплуатационные статьи считаются за оставшиеся месяцы, а не за двенадцать.
Второй год — только владение и развитие. Ориентир: 25–35% от стоимости разработки, из которых 15–20% на поддержку, остальное на новые функции. Для приложения за 900 тыс ₽ это 225–315 тыс ₽ в год, плюс инфраструктура и сервисы.
Отдельный совет для тех, кто верстает бюджет прямо сейчас: заложите одно крупное обновление в год. Системы обновляются ежегодно, требования сторов меняются, и раз в год приложению нужен полноценный подход, а не только мелкие правки.
04 · Что забывают включить
- Ежегодный аккаунт Apple. Мелочь, но без неё приложение перестанет обновляться.
- Продвижение. Если рассчитываете на новых пользователей, а не только на текущую базу, бюджет на привлечение может быть сопоставим с разработкой.
- Обучение сотрудников. Админка бесполезна, если ей никто не умеет пользоваться. Пара часов на команду — но их надо запланировать.
- Изменения в законодательстве. Требования к персональным данным ужесточаются; резерв на доработки под них — разумная предосторожность, особенно после роста штрафов (см. чек-лист по 152-ФЗ).
- Рост данных. База, которая летала на старте, на сотнях тысяч записей потребует более мощного сервера.
05 · Как не платить дважды
Самый частый конфликт «мы думали, это входит» лечится тремя строками в договоре:
- Гарантия — бесплатное исправление того, что подрядчик сделал не так. Срок фиксируется.
- Поддержка — сохранение работоспособности: обновления под новые системы, реакция на сбои.
- Развитие — новые функции, оцениваются отдельно с собственным сроком и демо.
Что именно спрашивать у подрядчика до подписания — в статье «7 вопросов до договора».
06 · Шаблон на год
Скелет, который можно перенести в свою таблицу:
- Разработка первой версии или крупного обновления — разово.
- Поддержка — помесячно, 15–20% годовых от стоимости разработки.
- Инфраструктура — помесячно.
- Внешние сервисы — помесячно, с запасом на рост.
- Магазины — ежегодный платёж Apple.
- Развитие — квартальный резерв.
- Продвижение — если нужны новые пользователи.
- Резерв 10–15% — на непредвиденное.
Если планируете приложение на 2027 год — напишите, что за задача и в каком объёме. Соберём бюджет по этим статьям с реальными цифрами, чтобы вы защитили его перед своим руководством, а не гадали на круглых суммах. Быстро прикинуть первую строку можно в калькуляторе.
07 · Частые вопросы
Сколько закладывать на второй год?
25–35% от стоимости разработки: 15–20% поддержка, остальное развитие. Плюс инфраструктура и внешние сервисы отдельной строкой.
Что забывают чаще всего?
Ежегодный аккаунт Apple, платные сервисы, продвижение, обучение сотрудников и резерв на изменения законодательства.
Как считать, если приложения ещё нет?
Разделите год на разработку (350 тыс – 1,5 млн ₽ по формату) и эксплуатацию с момента релиза, а не с января.
Как не платить за доработки дважды?
Разделить в договоре гарантию, поддержку и развитие — три разные строки с разными правилами.