Сколько стоит редизайн мобильного приложения в 2026 году

Три диапазона стоимости

Ниже приведены рабочие диапазоны Appfyl для приложения под iOS и Android. Они включают внедрение, тестирование и публикацию, а не только макеты. Это не средняя цена по рынку: итог зависит от состояния текущего продукта.

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

Сначала выясните, где заканчивается работа подрядчика

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

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

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

Не обещайте сохранить старый код до аудита

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

Продуктовая часть аудита отвечает на вопросы: где люди уходят, на что жалуются, какие действия приносят выручку и что действительно нужно изменить. Техническая проверка охватывает репозитории, инструкцию по сборке, архитектуру, зависимости, сервер, окружения, тесты, отчеты об ошибках и историю публикаций. Отдельно полезно собрать все компоненты интерфейса и найти лишние варианты одного и того же элемента.

В результате должна появиться карта решений:

• оставить без существенных изменений;
• сохранить за понятным программным интерфейсом;
• привести код в порядок до добавления новых функций;
• заменить, потому что риск выше возможной экономии;
• дополнительно исследовать в ограниченный срок и за заранее согласованную цену.

В разборе как улучшать UX на основе фактов хорошо показана ценность исследования до визуальных решений. Наблюдения, данные и проверяемые гипотезы дают проекту опору, которой нет у просьбы «сделать посовременнее».

Что можно сохранить, даже если приложение придется переписать

Ценность старого продукта не равна ценности его мобильного кода. Можно сохранить бренд, карточку в магазинах, тексты, аккаунты, историю заказов, надежную серверную часть и договоренности с платежными или другими сервисами. Документированные правила и автоматические тесты помогут точно восстановить поведение нового модуля.

Надежнее всего повторно использовать то, у чего понятны владелец, входные данные, результат и ограничения. Работающая оплата с возвратами и сверкой операций имеет очевидную ценность. Красивый экран без ошибок, состояний загрузки и связи с реальными данными может не сэкономить ни дня.

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

Работающее приложение похоже на мост, по которому уже идет движение. Покрасить исправную конструкцию, усилить опоры и построить рядом новый переход — три разных проекта. В приложении роль движения выполняют пользователи, их данные, подписки и незавершенные операции.

Из каких работ складывается бюджет

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

Система интерфейса. Шрифты, цвета, отступы, кнопки, поля, иконки и правила для текста должны складываться в набор повторно используемых компонентов. В нем нужны состояния загрузки, пустого результата, ошибки, блокировки и доступности, а также осмысленные отличия iOS от Android.

Мобильная разработка. Компоненты связываются с навигацией, разрешениями, уведомлениями, локальным хранением и возможностями телефона. Если макеты не учитывают устройство старого приложения, внедрение окажется дороже ожидаемого.

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

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

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

Перенос данных нужно считать отдельно

Новое приложение начинает работу с пустой историей. Обновленное получает старые данные и привычки пользователей. До разработки следует описать, что произойдет, если человек обновится с очень старой версии, вернется к незавершенному заказу или откроет ссылку из прежнего уведомления.

Проверьте шесть групп:

1. Идентификаторы аккаунтов, действующие сеансы и восстановление доступа.
2. Подписки, покупки, бонусы и незавершенные возвраты.
3. Избранное, черновики и сведения, сохраненные только на устройстве.
4. Ссылки из писем, уведомлений и других приложений.
5. Связь старых и новых пользователей и событий в аналитике.
6. Возможность поддержки увидеть версию и этап переноса.

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

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

Три примера с разным объемом работ

Приложение для записи с надежной технической частью. Люди путаются при выборе услуги, времени и условий отмены, но расписание работает, а обновления выходят стабильно. Здесь разумно переработать эти сценарии, собрать единые компоненты, внедрить и измерить результат. Переписывать авторизацию и систему записи незачем.

Интернет-магазин с разрозненным интерфейсом. Каталог и заказы работают, но корзина, личный кабинет и программа лояльности устроены по-разному. Каждое обновление ломает соседние функции. Вероятный путь: сохранить товарные данные и надежные интеграции, заново собрать мобильные компоненты и привести в порядок границы оформления заказа.

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

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

Как уменьшить стоимость без самообмана

Самая надежная экономия — выбрать один измеримый результат первой версии. Например, повысить долю завершенных регистраций, увеличить число записей или сократить обращения в поддержку. Переработайте связанные сценарии, а независимые идеи перенесите на следующий этап.

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

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

На время миграции заморозьте новые функции, которые не нужны для совместимости или выбранного результата. Если одновременно менять интерфейс, архитектуру и постоянно добавлять идеи, смета перестает быть проверяемой.

Как выглядит нормальное предложение подрядчика

В хорошем предложении указаны текущие версии, целевые платформы, пользовательские сценарии и все группы работ. Мобильное приложение, сервер, админ-панель, миграция, тестирование и публикация разделены. Предположения о повторном использовании записаны, как и порядок действий, если аудит их не подтвердит.

Критерии приемки должны описывать поведение. «Современный и удобный дизайн» нельзя проверить объективно. «Существующий пользователь сохраняет данные, проходит новый сценарий записи и получает правильное напоминание» можно.

Насторожитесь, если подрядчик:

• обещает сохранить весь код, не получив к нему доступ;
• считает только идеальные экраны без ошибок и пустых состояний;
• не упоминает старые данные и совместимость версий;
• не закладывает аналитику, отслеживание сбоев и план возврата;
• полностью перекладывает тестирование и публикацию на заказчика;
• выбирает технологию до изучения продукта и кода.

Для проверки прав, оплаты и приемки используйте также чек-лист договора на разработку приложения.

Выпускайте новую версию постепенно

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

Apple позволяет распределить подходящее обновление на семь дней с помощью поэтапной публикации. В Google Play есть постепенное развертывание, которое можно остановить. Эти механизмы уменьшают число затронутых людей, но не исправляют ошибки миграции.

Заранее договоритесь, когда останавливать публикацию: например, при росте сбоев, проблемах с оплатой, неработающем восстановлении аккаунта или резком падении завершения основного сценария. Для этого нужны правильно настроенные события. Они описаны в руководстве по аналитике приложения, а техническая проверка — в чек-листе тестирования перед запуском.

Как Appfyl оценивает редизайн

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

В оценке видно, что будет обновлено, приведено в порядок, заменено или сознательно сохранено. Перенос данных, админ-панель, тестирование и постепенная публикация указаны отдельными работами. Так объем можно сократить честно, не делая вид, что существующих пользователей и данных нет.

Первичную информацию можно собрать в интерактивном брифе Appfyl. Укажите ссылку на текущее приложение, проблемные сценарии, доступные материалы и жесткие сроки. Подробнее о нашей работе: разработка мобильных приложений Appfyl.

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

Частые вопросы