Поддержка и развитие продукта после релиза: что входит и как не переплатить
Приложение выложили, команда разошлась, продукт работает. Через год он пропадает из выдачи магазина для новых пользователей, и никто в компании не может сказать почему. Мы в Code Pilots ведём продукты после релиза и знаем цену такой паузы: заказная система стареет сама, без единой правки с вашей стороны. Платформы под ней меняются по расписанию.
Если совсем коротко. Поддержка держит продукт живым, развитие двигает его вперёд, и это две разные строки бюджета. Смешивать их нельзя — инциденты всегда съедают развитие. Уровень реакции покупают не «повыше», а под цену собственного простоя.
Ближайшая дата, которая касается всех владельцев Android-приложений, — 31 августа 2026 года. Что именно происходит в этот день, разобрано ниже.
Продукт стареет без вашего участия
Владелец продукта обычно считает, что без новых требований бизнеса приложение можно не трогать. Магазины приложений считают иначе, и у них есть даты.
| Витрина | Что требуют | С какой даты | Что будет без выполнения |
|---|---|---|---|
| App Store | Собирать приложение в Xcode 26 с SDK iOS 26 | 28 апреля 2026 | Загрузка новой версии в App Store Connect не принимается |
| App Store | Заново ответить на вопросы возрастного рейтинга | 31 января 2026 | Обновления приложения не проходят |
| Google Play | Действующим приложениям — Android 15 (API 35) и выше | 31 августа 2026 | Приложение перестаёт быть доступно новым пользователям на устройствах с более свежей версией системы |
| Google Play | Новым приложениям и обновлениям — Android 16 (API 36) | 31 августа 2026 | Сборку не принимают на публикацию |
| RuStore | Предустановка обязательна на смартфонах и планшетах | 1 сентября 2025 | Третья витрина со своими требованиями и своей модерацией |
Продление у Google Play предусмотрено — до 1 ноября 2026 года, форму запроса открывают в консоли разработчика. Это отсрочка на два месяца, и на этом всё.
Отдельная деталь, которую обычно не закладывают в план. Приложение, пересобранное с SDK iOS 26, по умолчанию получает новое оформление системных элементов интерфейса. Формально работа звучит как «обновить сборку», по факту к ней добавляются проверка всех экранов и решение дизайнера, оставлять новый вид или отключать.
Что скрывается за словом «поддержка»
Под одним словом живут четыре разных слоя работ, и стоят они по-разному.
Реакция на инциденты. Приложение упало, оплата не проходит, обмен с учётной системой встал. Работа непредсказуемая по объёму и требует дежурства.
Профилактика. Обновление зависимостей, продление сертификатов, чистка логов, проверка резервных копий, слежение за местом на дисках. Работа предсказуемая и дешёвая ровно до того момента, пока её не перестают делать.
Мелкие доработки. Поправить текст, добавить поле в форму, поменять правило расчёта скидки. Формально это уже развитие, но по объёму — задача на пару часов, и выносить её в отдельный контракт бессмысленно.
Работа с витринами. Выпуск сборок и прохождение модерации, ответы на отзывы, слежение за рейтингом и за тем, не сняли ли приложение с публикации. Слой незаметный до первого отказа модерации перед сезоном продаж.
Первая линия помощи конечным пользователям — отдельная история. Она живёт в системе заявок и по людям устроена иначе; как такую систему устраивают изнутри, разобрано в материале про service desk.
Где заканчивается поддержка и начинается развитие
Граница проходит по одному признаку. Поддержка возвращает продукт в то состояние, в котором он должен быть. Развитие меняет это состояние.
Практический смысл границы — в бюджете. Когда обе строки живут в одном договоре и в одной очереди задач, побеждают инциденты. Они срочные и заметные, поэтому уходят в работу первыми. Новые функции откладываются каждый спринт, и через год выясняется, что за год продукт не изменился, хотя деньги платили исправно.
Поэтому объём поддержки фиксируют отдельно, а развитие планируют своим бюджетом и своим приоритетом. Даже простое разделение двух строк в одном договоре уже меняет картину: становится видно, сколько на самом деле уходит на удержание.
Три модели работы
Выбор модели зависит от того, сколько стоит час простоя и как часто продукт меняется.
| Модель | Как устроена | Кому подходит |
|---|---|---|
| По инцидентам | Платите за разбор конкретного обращения, дежурства нет | Внутренние системы, где простой в один день терпим |
| Абонентская | Фиксированный объём часов в месяц, согласованное время реакции, остаток часов уходит на профилактику и мелкие доработки | Основная модель для продуктов с внешними пользователями |
| Выделенная команда | Постоянный состав работает над продуктом и закрывает поддержку и развитие одним потоком | Продукты, которые меняются каждый месяц и приносят выручку напрямую |
Модель по инцидентам выглядит самой дешёвой и часто ей и оказывается. Ловушка в другом: подрядчик без абонемента не держит людей в контексте вашего проекта, и первое же обращение начинается с погружения. Реакция при этом измеряется днями.
При смене подрядчика или модели закладывают переходный период. Первые четыре-шесть недель новая команда работает медленнее обычного: читает код, принимает доступы, собирает окружение и разбирает накопленные обращения. Этот срок стоит проговорить в договоре отдельно, иначе он воспринимается как срыв обязательств.
Какой SLA вам действительно нужен
Соглашение об уровне сервиса продают как достоинство. Чем быстрее реакция и шире окно дежурства, тем предложение выглядит солиднее. Считать надо иначе — от цены собственного простоя.
| Класс | Окно и реакция | Когда оправдан |
|---|---|---|
| Базовый | Рабочие дни, реакция в течение рабочего дня | Внутренние инструменты, административные панели |
| Стандартный | Рабочие дни, реакция в течение часа-двух, критичные обращения вне очереди | Клиентские приложения и сайты с обычным графиком продаж |
| Расширенный | Дежурство по звонку в вечернее время и выходные | Продукты, где выручка идёт круглосуточно |
| Круглосуточный | Смены 24×7, реакция в минутах | Платежи, доставка, всё, где отказ измеряется деньгами в час |
Разница между третьим и четвёртым классом больше, чем кажется. Дежурство по звонку означает, что человек доступен и подключится. Смена 24×7 означает, что люди работают ночью посменно, и оплачивается это соответственно.
В договоре важнее скорости ответа две другие вещи. Первая — время восстановления работы, а не время первой реплики в чате. Вторая — что именно считается критичным обращением: этот список формулируют заранее и без него SLA превращается в спор при каждом инциденте.
Третья вещь, о которой вспоминают уже в конфликте, — порядок эскалации. В договоре указывают, к кому обращение поднимается, если срок нарушен, и в какой момент подключается руководитель со стороны подрядчика. Уровень сервиса без такого пункта держится на доброй воле дежурного.
Мониторинг: кто узнаёт о сбое первым
Поддержка без мониторинга сводится к ожиданию жалобы. О проблеме сообщает пользователь, а часть пользователей просто уходит молча.
Минимальный набор наблюдения выглядит одинаково почти у всех продуктов. Доступность сервиса снаружи, ошибки приложения с трассировкой, время ответа ключевых операций, состояние очередей и обменов, свободное место и сроки действия сертификатов. Сверху — оповещение в мессенджер с указанием, кто дежурит.
Отдельно настраивают контроль бизнес-показателей. Число оплат в час, количество регистраций, объём выгруженных заказов. Технически всё бывает зелёным, а оплаты не проходят из-за смены реквизитов у провайдера — такое ловится только счётчиком продаж.
Второй по частоте дефект после отсутствия мониторинга — избыток оповещений. Когда в дежурный чат падает двести сообщений в сутки, их перестают читать целиком, и настоящая авария теряется в потоке. Оповещения регулярно прореживают, оставляя те, на которые есть конкретное действие.
Настройку мониторинга разумно сделать частью приёмки продукта, до того как команда разработки разойдётся. Позже это отдельная работа, и стоит она дороже.
Обновления, которые нельзя пропустить
Часть работ в поддержке не связана с вашими задачами вообще. Их задаёт внешний мир.
Библиотеки и фреймворки выпускают версии с исправлениями безопасности. Пропуск двух-трёх крупных версий превращает обновление из рутины в проект: ломаются интерфейсы, меняются зависимости, требуется переписывать куски кода.
Версии платформ идут по расписанию магазинов. Приложение на Android нужно пересобирать под новый целевой уровень API ежегодно, и разработка под Android без этого цикла невозможна в принципе. С 31 августа 2026 года действующим приложениям нужен как минимум Android 15, а новым сборкам — Android 16.
Каждое такое обновление обязательно проходит проверку. Пересборка под новый SDK меняет поведение системных компонентов, и без регрессионного тестирования дефекты находят пользователи после выкладки.
Три витрины вместо двух
Российский продукт живёт в трёх магазинах, и каждый добавляет свой цикл.
App Store требует сборку под актуальный SDK и проводит ручную модерацию каждой версии. Разработка под iOS у нас идёт на Flutter из одной кодовой базы, но требования магазина от стека не зависят.
Google Play проверяет целевой уровень API и политику по разрешениям, а сроки объявляет заранее и переносит редко.
RuStore обязателен к предустановке на смартфоны и планшеты с 1 сентября 2025 года по закону о защите прав потребителей. Магазин добавляет свою модерацию и свои требования к сборке, и для многих продуктов он уже основной канал установок.
Практический вывод простой. Релизный цикл планируют не по одной витрине, а по самой медленной из трёх, и закладывают время на повторную модерацию после отказа.
Что отваливается, если поддержку не оплачивать
Деградация идёт не разом, а по шагам, и каждый следующий дороже предыдущего.
Первые месяцы. Мелкие дефекты копятся, пользователи привыкают их обходить. Внешне всё нормально.
Полгода. Истекает сертификат или меняется API платёжного провайдера, часть функций отваливается. Починка занимает недели, потому что в проект надо возвращаться с нуля.
Год. Приложение не соответствует требованиям магазина. Действующие пользователи продолжают им пользоваться, новые перестают его находить, установки падают.
Полтора-два года. Накопленный пропуск обновлений превращает возврат в проект. Обновить всё разом уже нельзя, и разговор переходит в плоскость модернизации системы, где выбирают между ремонтом и переписыванием.
Дешевле всего вмешаться на первом шаге. Дороже всего — на последнем, и там цена сопоставима с новой разработкой.
Передача проекта другому подрядчику
Момент, когда теряют больше всего. Проект передают на словах, а через месяц выясняется, что половины доступов нет.
| Что передают | Почему это критично |
|---|---|
| Исходный код и история изменений | Без истории неясно, зачем сделана каждая правка |
| Ключ подписи Android-приложения | Без него обновить приложение в магазине невозможно |
| Учётные записи разработчика в магазинах | Аккаунт должен быть оформлен на вашу компанию, а не на подрядчика |
| Доступы к серверам, базам и системам сборки | Иначе выкладка новой версии невозможна физически |
| Домены, сертификаты, почта, платёжные кабинеты | Продлевать их будет некому |
| Документация и описание процессов | Сокращает погружение новой команды с месяцев до недель |
| Права на код по договору | Без них любая доработка юридически спорна |
Ключ подписи заслуживает отдельного абзаца. Если приложение публиковали с подключённым сервисом подписи Google Play, утрата ключа загрузки решается созданием нового. Если этот сервис не подключали при первой публикации и ключ потерян, обновить приложение уже нельзя — остаётся выложить новое с другим идентификатором пакета и потерять всю базу установок, отзывы и позиции в магазине.
Проверять всё это надо до окончания договора с прежней командой. Пока он действует, вопросы решаются письмом.
Четыре цифры вместо количества тикетов
Отчёт «за месяц закрыто 47 обращений» не говорит ни о чём. Работает поддержка или нет, видно по другим показателям.
Время до восстановления. Сколько проходит от сбоя до момента, когда всё снова работает. Именно это чувствует пользователь.
Доля повторных обращений. Если одна и та же проблема возвращается, её лечили симптоматически. Высокая доля повторов означает, что деньги уходят на бесконечное тушение.
Доля бюджета на инциденты. Больше половины — команда не развивает продукт, а удерживает его.
Возраст зависимостей. Насколько отстали используемые библиотеки и версии платформ. Показатель скучный, зато он единственный предсказывает следующий дорогой квартал.
Эти четыре цифры полезно запрашивать ежемесячно и смотреть в динамике. Абсолютные значения у всех разные, а направление говорит само за себя.
Своя команда или подрядчик
Условие выбора одно и оно не про стоимость. Своя команда оправдана, когда продукт меняется постоянно и является для компании основным. Тогда контекст должен жить внутри.
Во всех остальных случаях штатный разработчик под продукт, который меняется раз в квартал, простаивает или занимается чем-то посторонним. При этом он остаётся единственным носителем знаний, и его отпуск становится риском.
Смешанная схема встречается чаще всего. Внутри держат продакта и аналитика, которые понимают процесс и ставят задачи. Разработку, дежурство и выпуск релизов ведёт подрядчик по договору с зафиксированным уровнем сервиса.
Подрядчика на входе проверяют четырьмя вопросами. Кто конкретно будет дежурить по вашему продукту и что происходит с реакцией в отпуск этого человека. Как считается время восстановления и с какого момента идёт отсчёт. Что произойдёт с доступами и ключом подписи при расторжении договора. Как выглядит ежемесячный отчёт и попадают ли в него повторные обращения. Ответы на эти вопросы говорят о команде больше, чем список кейсов.
Сколько стоит
Стоимость поддержки складывается из уровня дежурства, потока обращений и объёма профилактики. Средняя цифра по рынку тут бесполезна: продукт с двумя витринами и десятью обменами и внутренняя панель отличаются в разы.
Ориентиры по смежным работам такие. Аудит унаследованного кода и архитектуры обходится от 200 до 600 тыс. ₽, настройка мониторинга и процессов выкладки отдельной услугой — от 200 тыс. ₽, крупный блок развития, сопоставимый по объёму с новым продуктом, считается как заказная разработка — от 1,7 млн ₽. Стоимость самой поддержки собираем по вашему продукту: оценка проекта бесплатная.
Порядок бюджета можно прикинуть заранее — бесплатный калькулятор оценки собирает вилку по составу работ за несколько минут.
Пять дорогих ошибок
Поддержку не закладывают в бюджет проекта. Продукт сдают, денег на сопровождение нет, и первые полгода он живёт на энтузиазме.
Развитие и инциденты держат в одной очереди. Срочное побеждает всегда, и через год продукт не изменился.
Мониторинг ставят после первого крупного сбоя. До этого о проблемах узнают из отзывов в магазине.
Аккаунты разработчика оформляют на подрядчика. При смене команды приложение фактически остаётся у прежней.
Покупают круглосуточное дежурство «на всякий случай». Платят за смены, которые ни разу не понадобились, вместо профилактики и обновлений.
С чего начать
Первое — посчитать цену простоя. Сколько компания теряет за час и за сутки недоступности продукта. Эта цифра определяет нужный уровень дежурства и закрывает спор о SLA.
Второе — проверить доступы. Кому принадлежат аккаунты в магазинах, где лежит ключ подписи, кто продлевает домены и сертификаты. Проверку делают до того, как она понадобится срочно.
Третье — разделить две строки бюджета. Отдельно удержание продукта, отдельно его развитие, с разными приоритетами и разными исполнителями внутри команды.
Часто задаваемые вопросы
Потому что требования вокруг него меняются без вашего участия. Магазины назначают даты по версиям систем, платёжные провайдеры меняют интерфейсы обмена, сертификаты истекают, в библиотеках находят уязвимости. Продукт, к которому не притрагивались год, обычно теряет часть функций и выпадает из выдачи магазина для новых пользователей. Возврат обходится дороже, чем регулярное сопровождение.
Состав работ, время реакции и время восстановления по классам обращений, список того, что считается критичным, канал подачи заявок и порядок отчётности. Отдельно фиксируют, что входит в абонемент, а что считается развитием и оценивается сверх него. Без этого разделения каждая вторая задача превращается в переговоры.
Можно, и это обычная практика. Новая команда начинает с аудита кода и приёма доступов, дальше месяц-полтора идёт погружение, во время которого скорость реакции ниже обычной. Главное сделать заранее — убедиться, что аккаунты в магазинах, домены и ключ подписи приложения принадлежат вашей компании.
Требований магазинов у сайта нет, но остальное совпадает. Обновления библиотек и версии серверного окружения, продление сертификатов, резервные копии, уязвимости в используемых компонентах. Отличие в том, что у сайта проблема видна сразу и всем, а у приложения она может месяцами жить только у части пользователей.
По времени восстановления, доле повторных обращений и возрасту зависимостей. Если одни и те же проблемы возвращаются, а библиотеки отстают на несколько версий, объём отчётов и количество закрытых заявок ничего не меняют. Хорошая поддержка со временем делает продукт спокойнее, и число срочных обращений снижается.
Разработка с Code Pilots
Code Pilots — студия заказной разработки полного цикла: веб- и мобильные продукты со сложной бизнес-логикой, интеграциями и высокими нагрузками. Продукты после релиза мы ведём тем же составом, который их делал. Настраиваем мониторинг и оповещения, держим согласованный уровень реакции, обновляем зависимости и версии платформ, выпускаем релизы в App Store, Google Play и RuStore, принимаем проекты от предыдущих подрядчиков вместе с аудитом кода.
Границы проговариваем сразу. Поддержку серверного парка предприятия, рабочих мест сотрудников и колл-центр первой линии для конечных пользователей выполняют другие подрядчики. Мобильная часть у нас идёт на Flutter из одной кодовой базы под обе платформы.
Внутри — аналитики с отраслевой экспертизой, дизайнеры, backend- и мобильные разработчики, QA и DevOps, middle+ и senior. Цену и объём фиксируем до старта. Пришлите цену часа простоя и список того, где лежат ваши доступы: по этим двум вещам уже видно, какой уровень сопровождения вам нужен. Обсудить проект →
