Приложение вышло в магазин, пользователи начали им пользоваться, а в бюджете осталась одна строка: «поддержка». Что в ней учитывать — исправление ошибок, новые функции, серверы, выпуск обновлений? И означает ли оплаченный пакет часов, что команда подключится ночью, если перестанут проходить заказы?
Стоимость поддержки складывается из работы специалистов, расходов на инфраструктуру и внешние сервисы, а также согласованных условий доступности команды. Чтобы получить бюджет в рублях, нужны объем задач, ставки специалистов и режим сопровождения. Одна цена «за приложение в месяц» без этих условий не позволяет сравнить предложения.
Я занимаюсь разработкой в Mobecan. На нашей странице поддержки приложений указан минимальный пакет 30 часов: стоимость зависит от состава специалистов. Ниже покажу, как разобрать такую оценку и какие расходы проверить до старта. Условия услуги проверены 20 сентября 2026 года.
За что вы платите после запуска
Удобно разделить бюджет на три части. Первая — сохранить работоспособность существующего продукта. Вторая — изменить его возможности. Третья — оплачивать сервисы, от которых он зависит.
| Статья расходов | Что уточнить в предложении |
|---|---|
| Диагностика и исправление ошибок | Включены ли воспроизведение проблемы, поиск причины и проверка исправления |
| Совместимость и зависимости | Какие устройства и версии ОС проверяются; какие обновления библиотек запланированы |
| Тестирование и выпуск | Кто проверяет связанные сценарии, готовит сборку и сопровождает релиз |
| Новые функции | Есть ли отдельная оценка; сколько часов остается на текущие проблемы |
| Серверная часть и инфраструктура | Кто отвечает за API, базы данных, резервные копии и мониторинг |
| Внешние сервисы | Кто оплачивает хостинг, СМС, другие платные интеграции и аккаунты магазинов |
| Работа с инцидентами | В какие часы команда доступна и что происходит при аварии вне этого времени |
Поддержка мобильного клиента не обязательно включает серверную часть. В условиях Mobecan backend, инфраструктура, мониторинг и обращения конечных пользователей обсуждаются отдельно. В смете другого исполнителя границы могут отличаться — проверяйте состав работ, а не только итоговую сумму.
Как посчитать пакет из 30 часов
Если все работы оплачиваются по одной согласованной ставке, расчет простой: 30 часов × ставка за час. Если ставки зависят от роли, нужно сложить стоимость работы каждого специалиста.
Например, для объяснения расчета возьмем условное распределение: 18 часов разработки, 8 часов тестирования и 4 часа на координацию и подготовку выпуска. Всего 30 часов. Это учебный пример, не типовой состав пакета Mobecan и не обещание выполнить любой набор задач за это время. В реальной оценке выпуск могут учитывать в часах разработчика, а состав ролей будет другим.
Стоимость такого примера = 18 × ставка разработчика + 8 × ставка тестировщика + 4 × ставка координатора. Умножать все часы на самую низкую ставку из предложения неправильно, если задачи выполняют разные специалисты.
Чтобы из стоимости пакета получить бюджет на месяц, добавьте согласованные расходы на серверы и сервисы, отдельные работы и, если предусмотрено условиями, оплату дежурства. Уточните, включены ли применимые налоги в предложенные суммы. Не складывайте повторно то, что уже входит в пакет.
Минимальный пакет 30 часов сам по себе не означает ежемесячную абонентскую плату, 30 часов только программирования или круглосуточное обслуживание. Период использования, перенос остатка, порядок учета времени и доступность команды нужно согласовать отдельно.
Почему первый месяц может стоить дороже
Когда проект принимает новая команда, часть времени уходит на знакомство: проверить исходники, воспроизвести сборку, разобраться в интеграциях и понять, как выпускались обновления.
Эту работу полезно вынести в отдельный этап. Иначе вы сравниваете месячный бюджет действующего подрядчика, который уже знает систему, с бюджетом новой команды, включающим ее приемку.
Попросите две оценки: вход в проект и последующее сопровождение. В первой должны быть проверяемые результаты — рабочая сборка, список рисков и понятный процесс выпуска. Во второй — задачи, режим работы и способ контроля бюджета. Подробный перечень материалов есть в чек-листе передачи приложения новому подрядчику.
Если проект давно не обновлялся, команда может обнаружить дополнительные препятствия. Но необходимость восстановить сборку еще не доказывает, что приложение нужно переписать. Сначала стоит выяснить причину и оценить варианты.
Почему «маленькая правка» требует тестирования
Представим приложение доставки: после изменения корзины нужно проверить не только итоговую сумму на экране, но и передачу заказа, применение бонусов и связанные сценарии оплаты. Это пример проверки, а не описание конкретного инцидента клиента.
В разработанном нами приложении «Вкус и Лосось» есть корзина, бонусная программа, авторизация и уведомления о статусах заказа. Публичный кейс показывает, сколько связанных сценариев может быть у продукта. Бюджет его сопровождения здесь не приводится.
Поэтому сравнивать предложения только по часам написания кода неудобно. У одного подрядчика проверка и выпуск уже учтены, у другого появятся отдельной строкой. Попросите оценить весь путь задачи: диагностику, изменение, проверку и доставку обновления пользователям.
Пакет часов, работа по задачам или выделенная команда
Пакет часов позволяет заранее ограничить объем расходов и выбрать приоритеты. При этом нужно понимать, как согласуются задачи сверх пакета и что происходит с неиспользованным остатком.
Оплата отдельных задач удобна, когда изменения редкие и их можно четко описать. Доступность исполнителя для следующей срочной задачи стоит обсудить заранее: выполненная разовая работа сама по себе ее не гарантирует.
Выделенная команда или зарезервированная загрузка имеет смысл рассматривать при постоянном потоке изменений. Здесь вы оплачиваете определенный объем участия специалистов, поэтому важно иметь подготовленные задачи и человека со стороны бизнеса, который принимает решения.
Ни одна модель не заменяет договоренности о приоритетах, приемке и авариях. Для сравнения попросите исполнителей оценить один и тот же список задач при одинаковом режиме работы.
Что означает SLA и за что здесь платить
Для бизнеса важен конкретный сценарий: в пятницу вечером пользователи не могут оформить заказ. Кто получит сигнал, когда начнет разбор и кто вправе временно отключить проблемную функцию?
Время реакции — это начало обработки обращения. Время восстановления — момент, когда согласованный сервис снова работает. Окончательное исправление причины может потребовать отдельной работы. Эти сроки не стоит смешивать в одно обещание «решаем за час».
Если вам нужна доступность вечером и в выходные, включите ее в запрос на оценку. Согласуйте критичные сценарии, каналы уведомления, ответственных и временные меры. Обычный пакет разработки не дает оснований рассчитывать на дежурство 24/7.
Как снизить расходы без потери контроля
Начните с порядка в задачах. Для ошибки полезны версия приложения, устройство, шаги воспроизведения и ожидаемый результат. Не передавайте в обычной переписке пароли или выгрузки пользовательских данных: нужные материалы и безопасный способ доступа согласуйте с командой.
Разделяйте обязательные исправления и пожелания. Если в одном списке стоят сбой авторизации и новый цвет кнопки, часы легко потратить без заметного улучшения работы продукта.
По плановым изменениям обсуждайте объединение в релизы: это позволяет не повторять одну и ту же подготовку для каждой мелкой задачи. Критичные исправления при этом не нужно задерживать ради удобного графика.
Проверяйте отчет вместе с результатом: что изменилось, что проверено, что выпущено, какие вопросы остались. Одного перечня списанных часов недостаточно, чтобы понимать состояние приложения.
Что отправить для оценки поддержки
Для первого разговора достаточно ссылок на приложение в магазинах, описания основных проблем и ближайших задач. Дополнительно укажите платформы, известный стек, наличие исходников и требования к рабочему времени команды.
Попросите показать в ответе:
- стоимость входа в проект и результаты этого этапа;
- часы и ставки по ролям, состав тестирования и выпуска;
- расходы, которые не входят в предложение;
- порядок согласования превышения бюджета;
- режим обработки инцидентов и условия использования пакета.
В Mobecan рассматриваем нативные приложения iOS и Android и проекты на Flutter, в том числе после другой команды. Минимальный пакет — 30 часов; состав задач и стоимость согласуем после знакомства с проектом.
Получить оценку поддержки приложения в Mobecan. Опишите, что сейчас мешает работе и какие изменения нужны: это поможет начать с предметной оценки.