Короткий ответ: сколько стоит поддержка
Единой месячной цены нет. Для одного приложения достаточно разбора обращений и редких исправлений, другому нужны наблюдение за оплатой и заказами, дежурство, сервер и частые выпуски. Поэтому сначала определяют состав работ и режим реакции, а уже затем называют сумму. Ежемесячный бюджет удобно считать так: согласованный регулярный объём + утверждённые задачи сверх него + инфраструктура и внешние сервисы + отдельно запланированное развитие. Не каждое слагаемое обязательно и не каждое оплачивается одному подрядчику.
Для масштаба: FITTIN в публикации от 9 июля 2026 года указывает для своей платформы тариф ПРО от 150 000 ₽ в месяц, где поддержка включена в лицензию; отдельную поддержку стороннего приложения компания предлагает от 2 625 ₽ за час. Это цены одного поставщика за разные продукты и модели оплаты, а не средняя стоимость рынка и не предложение 13FOX. По ним нельзя умножить «типовое число часов» и получить бюджет вашего приложения.
Почему экран приложения не показывает объём поддержки
В нашем проекте CentreVisa клиент выбирает визовую услугу, заполняет анкету, видит статус заявки и задаёт вопрос консультанту в чате. Мы собрали эти действия в одном мобильном продукте. Для владельца подобного сервиса сбой не сводится к закрывшемуся приложению. Например, заявка может отправиться, но не появиться у команды, или статус обновится не там, где его ждёт клиент. Поэтому перед оценкой поддержки нужно перечислить ключевые действия и системы за экраном. Этот кейс показывает состав продукта; он не задаёт цену сопровождения.
Реальный проект 13FOX
CentreVisa: заявка живёт после отправки
Клиент видит статус визовой заявки и переписывается с консультантом. Для поддержки такого пути важна вся цепочка от анкеты до ответа команды.
Что входит в смету, а что оплачивается отдельно
Сначала отделите гарантийные исправления от дальнейшей эксплуатации. По гарантии устраняют дефекты в пределах согласованных условий сдачи проекта. Она не означает бессрочные обновления под новые правила магазинов приложений, новые функции или круглосуточное дежурство. Точные границы, срок и порядок обращения задаёт договор. Если ошибка затрагивает сданный сценарий, сначала проверьте её по гарантийным условиям. Исправления вне этих условий оценивают отдельно или включают в согласованный контур поддержки.
| Контур | Пример работы | Что записать в смете |
|---|---|---|
| Исправления | Воспроизвести ошибку входа, исправить и проверить выпуск | Что считается дефектом и какой результат принимается |
| Плановая поддержка | Разбирать сбои, проверять совместимость, собирать и выпускать версии | Канал обращений, график, приоритеты и объём работ |
| Размещение и сервисы | Сервер, хранение, сообщения, аналитика, внешние подписки | Кто оплачивает счета и кто получает уведомление о лимитах |
| Развитие | Новая оплата, роль сотрудника, программа лояльности | Отдельная оценка, приёмка и влияние на поддержку |
Обычные выпуски новых версий входят в поддержку только тогда, когда это записано в договоре. Публикацию в новом магазине и платежи за аккаунты площадок проверяйте отдельными строками. Проверьте также, кто отвечает за серверную часть и интеграции. Если «мобильная поддержка» ограничена сборкой приложения, исполнитель может честно исправить экран, но не устранить причину сбоя в API, платёжном сервисе или обмене с учётом. API позволяет приложению обращаться к серверу и внешним системам. Его граница должна быть видна в договоре.
Почему у похожих приложений разные расходы
Платформы и магазины. iOS и Android требуют отдельной проверки релизов и устройств, даже если приложение собрано из общей кодовой базы. На 23 сентября 2026 года Google Play требует целевой Android 16 (API 36) для новых приложений и обновлений, а для доступности существующего приложения новым пользователям действует другое правило. Apple требует Xcode 26 и соответствующий SDK для новых загрузок в App Store Connect. Такие изменения делают проверку и обновление реальной задачей поддержки, но не означают, что каждый месяц придётся переписывать продукт.
Обмен данными. У магазина заказ затрагивает приложение, сервер, оплату, склад и доставку. Если платёж прошёл, а подтверждение заказа не пришло, нужно выяснить, где цепочка остановилась, безопасно восстановить состояние и ответить покупателю. Чем больше сторонних систем и владельцев, тем больше времени уходит на поиск причины и согласование исправления.
Состояние проекта. Код, который собирается по инструкции, доступные тестовые окружения и журнал ошибок сокращают расследование. Если новому исполнителю сначала нужно восстановить сборку и разобраться с аккаунтами площадок, это разовая работа по передаче проекта, а не обычный месяц поддержки. Подробный список доступов есть в статье о правах на код и передаче приложения.
Как выбрать модель оплаты
По задачам. Подходит, когда обращений мало и нет обязательства дежурить в определённые часы. Каждую задачу описывают, оценивают и согласуют до работы. В договоре стоит решить, кто заметит сбой между обращениями и сколько стоит срочное подключение.
Регулярный объём. Команда резервирует время на обращения, плановые проверки и релизы. Уточните, включены ли неиспользованные часы в следующий месяц, как считаются работы сверх объёма и оплачивается ли само ожидание обращения. Абонентский платёж без этих ответов трудно сравнить с оплатой по задачам.
Дежурство с условиями реакции. Нужно продукту, где задержка при сбое оплаты, входа или выдачи услуги ощутима для клиентов. Тут платят и за готовность принять инцидент в согласованное время. В договоре нужно уточнить, считается реакцией подтверждение обращения или уже начало разбора. Ни то ни другое не обещает исправить любую ошибку к тому же часу. У 13FOX режим и условия уровня обслуживания (SLA) обсуждаются отдельно. На странице услуги круглосуточная поддержка по умолчанию не обещана.
Сравните одинаковый объём: в обоих предложениях должны совпадать часы доступности команды, поддерживаемые платформы, сервер и интеграции, порядок срочных работ, релизы и отчёт. Только после этого сопоставляйте суммы.
Как записать приоритет и время реакции
Фраза «срочно исправим» не помогает, когда приложение перестаёт принимать оплату вечером. Для договора опишите три части отдельно: когда принимают сообщения, когда подтверждают и начинают разбор, когда сообщают план восстановления. Время полного исправления зависит от причины и может потребовать действий внешнего сервиса или выпуска через магазин приложений. Такие зависимости тоже лучше назвать заранее.
| Приоритет | Пример критерия | Что согласовать |
|---|---|---|
| Критический | Не работает вход, оплата или основное действие у всех пользователей | Канал срочного сообщения, часы дежурства, начало разбора, временный обход |
| Высокий | Основное действие недоступно части пользователей, есть обходной путь | Порядок диагностики, срок обновления статуса, ближайший выпуск |
| Плановый | Небольшая ошибка без блокировки задачи или обновление компонента | Как задача попадает в план работ и кто утверждает оценку |
Скопируйте рабочую формулировку в запрос подрядчику: «Пришлите таблицу по каждому приоритету: критерий, канал сообщения, часы работы команды, время подтверждения, время начала диагностики, частота сообщения о статусе, ответственный за внешний сервис и условия срочного релиза». Числа подставляют после согласования бюджета и графика; сами названия приоритетов ничего не гарантируют.
Шаблон месячного бюджета для вашего приложения
Возьмите последний месяц обращений и заполните строки ниже. Если приложение ещё не выпущено, используйте план первой версии и отмечайте неизвестные пункты как вопросы, а не как ноль. Получится основа для одинакового задания двум командам.
| Строка | Ваши данные | Вопрос исполнителю |
|---|---|---|
| Продукт и площадки | Версии iOS/Android, магазины, число приложений | Какие сборки и релизы входят? |
| Ключевые операции | Вход, заказ, оплата, заявка и другие важные действия | Что наблюдают и как проверяют после исправления? |
| Обращения и сбои | Сколько пришло, какие повторяются, когда возникают | Какие обращения включены и как считают превышение? |
| Связанные системы | Сервер, оплата, система работы с клиентами (CRM), учёт, доставка | Кто диагностирует границу каждой системы? |
| Время реакции | Когда продукт критичен для пользователей | Какое дежурство и какие уведомления нужны? |
| Отдельные платежи | Хостинг, подписки, публикация, запланированные функции | Что выставят помимо поддержки и кто платит напрямую? |
Попросите итог в четырёх строках: регулярная сумма или резерв, условия для дополнительных задач, расходы третьих сторон, отдельный план развития. Для каждой строки нужны границы работ. Если предлагается фиксированная цена, пусть исполнитель перечислит, что считается сверх неё. Если расчёт идёт по времени, нужен журнал задач с согласованной оценкой и фактом.
Если приложение передаёт другая команда
Начните с проверки, а не с обещания «поддерживать всё». Новой команде нужны права на репозиторий (хранилище исходного кода), инструкция сборки, тестовая среда (отдельная копия для безопасной проверки), карта серверов и внешних сервисов, аккаунты площадок с подходящей ролью и список текущих ошибок. Секреты и пароли передают через защищённый канал после согласования доступа, а не в открытом письме.
Первый полезный результат — небольшой акт состояния. В нём записано, собирается ли приложение; какие ключевые операции проходят; где нет наблюдения за ошибками; кто владеет аккаунтами; какие проблемы требуют срочного ремонта. После этого можно разделить разовое приведение проекта в порядок и постоянный контур поддержки. Если сборка не воспроизводится, разумно сначала оценить восстановление, иначе месячный тариф скрывает неизвестную работу. Если проверки показывают отдельные неисправности, посмотрите варианты доработки мобильного приложения.
Источники и полезные продолжения
- FITTIN: собственные условия поддержки и цены, опубликовано 09.07.2026, проверено 23.09.2026.
- Google Play: требования к целевому уровню Android API, проверено 23.09.2026.
- Apple Developer: требования к загрузке приложений, проверено 23.09.2026.
- Apple: задачи после публикации приложения, проверено 23.09.2026.
- Firebase Crashlytics: сбор и группировка ошибок приложения, проверено 23.09.2026.
Если вы пока планируете создание продукта, начните с проверки задачи до разработки. Если приложение уже работает и вам нужен исполнитель, посмотрите поддержку мобильных приложений.
Частые вопросы
Сколько стоит поддержка мобильного приложения в месяц?
Месячная сумма зависит от того, какие платформы, серверы и интеграции входят в работу, сколько обращений возникает и в какие часы команда должна реагировать. Для ориентира FITTIN публикует тариф своей платформы от 150 000 ₽ в месяц с поддержкой в лицензии и отдельную поддержку стороннего приложения от 2 625 ₽ в час. Это разные предложения одного поставщика, не рыночная средняя и не цена 13FOX.
Гарантия после разработки заменяет поддержку?
Нет. Гарантийные исправления ограничены условиями договора и принятым объёмом работ. Обновления под изменения площадок, эксплуатация серверов, новые функции и постоянное дежурство требуют отдельного согласования.
Что означает время реакции в договоре?
В договоре нужно определить, означает ли реакция подтверждение обращения или начало диагностики в указанные часы. Её следует отличать от восстановления и полного исправления: они зависят от причины сбоя и внешних систем.
Можно ли передать приложение на поддержку другой команде?
Да. Сначала проверьте права на код и аккаунты, сборку, тестовую среду, ключевые операции и текущие ошибки. Разовое восстановление проекта и дальнейшую регулярную поддержку удобнее оценивать отдельно.
Разложим поддержку по понятным строкам
Пришлите ссылку на приложение, платформы, список ключевых действий и текущие проблемы. Мы проверим границы продукта, отделим разовое приведение в порядок от регулярной поддержки и подготовим предварительный состав работ и вопросы для оценки. На первом разговоре достаточно описания. Доступы можно обсудить позже.
Для первого разговора не нужны пароли и доступы к рабочим системам.