Приложение заказать или доработать старое: как принять решение

Когда доработка старого решения перестаёт быть оправданной

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

1. Разработка новых функций оборачивается цепной реакцией багов.

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

2. Сроки изменений превысили разумный уровень.

Если реализация средней по сложности фичи занимает 4–5 недель, когда аналогичные задачи в других проектах закрываются за 5–7 дней, стоит задать вопрос: не тянет ли старый стек всю команду вниз? Часто бизнес сравнивает стоимость новой разработки со стоимостью одной фичи — и ошибается. Подумайте — сколько стоит задержка выпуска целого пула фич из-за архитектурных ограничений?

3. Технологии, на которых построено приложение, больше не поддерживаются.

Когда компания работает на старом фреймворке, не получающем обновлений безопасности; когда нет возможности обновить систему на новые устройства iOS или Android, возникает уязвимость не только перед хакерами, но и перед банальным падением совместимости. Пример: CRM-система на AngularJS с кастомным бекендом, созданная в 2015 году, которая теперь не интегрируется с API современных маркетинговых сервисов — потому что отсутствует HTTPS SNI, который требуется большинству SDK.

4. Legacy-код блокирует развитие продукта.

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

5. Скрытые расходы

Редко учитывается управленческая издержка: на принятие решений из-за слабой документации уходит в 2–3 раза больше времени. В условиях роста команды и разработки под мультиплатформу (iOS, Android, веб) нагрузка на менеджмент кратно возрастает. Плюс: чтобы «держать старое» приходится «покупать» опыт узких специалистов по устаревшим технологиям, которых на рынке почти не осталось.

А стоит ли вам продолжать дорабатывать, если:

• Средняя фича занимает месяц, вместо 7–10 дней;
• При релизе количество багов стабильно превышает трёхзначные значения;
• Вы не можете нанять разработчика без месячного онбординга из-за сложности кода;
• Вы теряете премиум-клиентов из-за трений в UX или багов на последних iOS/Android.

Если на 2 и более пункта вы ответили «да» — разработка мобильных приложений с нуля может быть обоснованной инвестицией.

Что вы теряете, продолжая дорабатывать устаревшее приложение

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

1. Упущенное время вывода новых фич на рынок

Например, компания запускает акцию «Быстрая доставка документов за 3 часа». Конкуренты берут рынок с помощью обновления мобильного приложения, а у «наследственной» компании реализация замыкается на неподдерживаемом REST API, и весь релиз откладывается на месяц. Результат — маркетинг не сработал, польза от идеи теряется.

2. Потеря UX-качества

Пользовательский опыт — ключ к удержанию клиента. Наличие зависаний, невозможность использовать FaceID или Android Biometric Prompt, отваливающийся Bluetooth-подключение, долгая загрузка данных, отсутствие офлайн-доступа — всё это формирует негативный образ продукта. Архитектура, не поддерживающая адаптивные интерфейсы или PWA, рано или поздно «выталкивает» пользователя к конкуренту.

3. Ограниченное масштабирование и интеграция

Старое приложение может не поддерживать современные инструменты аналитики, BI, CDP или персонализации. Например, магазин персонализирует рекомендации через ML-алгоритмы — но ваш старый backend не умеет отдавать карточки товара по динамическим запросам. Вот и всё: кПИ в минус, ROAS в минус, бизнес-проблема без решения.

4. Стратегические потери

Возможно, вы планируете международную экспансию. А ваш старый стек не поддерживает многоязычные интерфейсы, локализацию валют, разные модели налогообложения или GDPR/CCPA/Закон о персональных данных. Разработка таких функций на устаревшей архитектуре приводит к срывам сроков и несоответствию регуляторике. Это не просто неудобство — это юридические риски и штрафы.

5. Потери команды

Разработчики не хотят годами исправлять баги в старом коде. Они хотят работать на современных технологиях с архитектурой, где можно внедрять тестирование, CI/CD, контейнеризацию, DevOps. Устаревшее приложение — фактор, отталкивающий сильных командных игроков. И наоборот, новые проекты привлекают разработчиков как вызов и возможность реализовать лучшие практики.

Когда оправдано приложение заказать «с нуля»

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

• Текущая система: нестабильна, не масштабируется, технический стек устарел.
• Цель: масштабировать бизнес, интегрироваться с новыми платформами, выйти на новые рынки, обеспечить стабильность.

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

Кейс 1: Выход на мобильный рынок

Компания имеет десктопное SaaS-решение, написанное более 7 лет назад. Клиенты просят мобильное приложение iOS + Android. Однако API не адаптированы под мобильные сценарии. Создание нового клиентского приложения (или гибридной платформы) вынуждает проводить рефакторинг backend, сетевую оптимизацию, разработку оффлайн-сценариев. В такой ситуации проще устройство создать с нуля под мобильные форматы, используя Flutter или Kotlin Multiplatform.

Кейс 2: Переход к подписной модели

Магазин со старой системой заказов внедряет рекуррентные платежи. Старый backend не поддерживает авторизацию по токену или работу с современными платёжными шлюзами (Stripe, CloudPayments, ApplePay, GooglePay). Поддержка превращается в «протаскивание телеги», где каждая фича превращается в 3 месяца испытаний. Заказ нового приложения позволит изначально включить современные API, тестировать и масштабировать по сегментам.

Кейс 3: Интеграция с внешними системами

Компания выходит на логистический рынок и должна интегрироваться с ERP, логическими платформами, BI-системами. Старое решение не выдерживает объёма событий, API самописные, нет очередей задач. В этом случае архитектура нового продукта должна опираться на шину событий (Kafka, RabbitMQ), нормальные протоколы (gRPC/RESTful), горизонтальное масштабирование и безопасность — без этого интеграция невозможна.

Что важно обсудить до старта проекта:

• Какой уровень пользовательского UX/дизайна вы видите?
• Есть ли потребность поддерживать работу без подключения к интернету?
• На какие устройства (iOS, Android, планшеты) целесообразно ориентироваться?
• Нужна ли интеграция с существующими внутренними системами (CRM, склад, бухгалтерия)?
• Какая политика конфиденциальности и обработки персональных данных должна быть соблюдена?

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

Как сравнить стоимость: доработка vs. разработка нового приложения

Решение «давайте доработаем, потому что это дешевле» — одно из самых ошибочных с точки зрения долгосрочного инвестирования в продукт. Причина кроется в неверной оценке полной стоимости владения (TCO), когда учитываются лишь текущие расходы и игнорируются золотые часы команды, UX-компромиссы и скорость реакции на рынок. Чтобы принять верное решение, необходимо сравнивать не разовые затраты, а совокупные издержки на поддержание и развитие функционала на период хотя бы в 12–24 месяца.

Что включает TCO приложения:

• Затраты на разработку и тестирование;
• Расходы на техническую поддержку и багфиксы;
• Инфраструктура (серверы, домены, облачные сервисы);
• Обучение и сопровождение команды;
• Ожидаемые инвестиции в новые функции;
• Неявные издержки: скорость релизов, отказоустойчивость, удовлетворённость пользователей.

Цифровой пример: при переходе с устаревшего backend (например, монолита на PHP 5.x) на современный микросервисный подход (Node.js + PostgreSQL + Docker), вы получаете возможность масштабировать производительность пропорционально трафику. При сохранении старой архитектуры высокая нагрузка приводит к сбоям — и каждое падение сервиса сдерживает продажи.

«Дорого» — понятие относительное

Если затраты на доработку старого решения в течение 6 месяцев составляют 2 млн ₽, а создание нового приложения — 4 млн ₽ и займет 4 месяца с возможностью последующего быстрого масштабирования и обновлений, то второй путь гораздо разумнее. Особенно, если при этом повышается стабильность, улучшается UX и достигается соответствие законодательным требованиям.

Сравнительная таблица: старое решение vs новое приложение

Как бизнесу рассчитать точку окупаемости?

Следует сравнить: сколько прибыли/экономии приносит за 12–18 месяцев стабильность интерфейса, ускорение вывода продукта на рынок, отсутствие багов и снижение затрат на поддержку. Если прирост более 30–40% по этим метрикам, создание нового приложения — оправдано. Работаем с этими данными и строим модели в Excel или BI-системе: карта затрат, NPV, ROI от заказа проекта — все точки сравнения лежат на поверхности, если включать цифры.

Что спросить у подрядчика, прежде чем приложение заказать

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

• Какие технологии вы рекомендуете и почему?
• Убедитесь, что подрядчик подходит технологически рационально, а не по привычке. Например, если вам нужна высокая кросс-платформенность — есть ли опыт с Flutter, React Native? Или они работают только на нативе?
• Как вы планируете реализовать интеграции с существующими системами (CRM, 1C, логистика)?
• Формулировка ответа покажет: команда работает системно или использует точечные хаки.
• Будет ли проведён аудит старой системы?
• Это обязательный этап. Без оценки текущего состояния платформы невозможно грамотно спланировать миграцию, распараллелить работы, вынести бизнес-логику. Уточните, входит ли discovery-фаза в смету?
• Как вы проектируете безопасность и политику конфиденциальности?
• Особенно важно при передаче и хранении персональных данных, авторизации, платежных данных. Должна быть предусмотрена система ролей, логирование действий пользователей, защита API, соответствие 152-ФЗ, GDPR.
• Как будет организовано масштабирование?
• Хорошая команда заранее продумывает архитектуру с возможностью роста — особенно если вы планируете вывод на iOS и Android, работу с разными версиями платформ, рост количества одновременных пользователей.

Дополнительно полезно запросить следующую информацию:

• Демо аналогичных проектов (кейсы с кратким описанием задач и решений);
• Сроки и команда на каждый этап разработки мобильного приложения;
• Примеры UI/UX-решений, которые они реализовали;
• Полный процесс: от сбора требований — до пилота и техподдержки.

Формат общения тоже многое подскажет. Если менеджер отвечает сухо или уходит от конкретики — это тревожный сигнал. Качественная команда способна расписать весь жизненный цикл приложения: от «мы создаем современное API» до «внедрим систему быстрых обновлений через Google Play + AppStore».

Как подготовиться к миграции: переход со старого на новое

Миграция — не драма, если она заранее спланирована. В нашей практике проекты с переходом на новое приложение с сохранением бизнес-логики происходят даже быстрее, чем доработка «по живому».

1. Что нужно предусмотреть при переносе данных

• Формат хранения данных: есть ли различия в полях, типах, кодировке?
• Обязанности по обеспечению чистоты базы данных: дубляжи, мусор, устаревшие поля?
• Нужен ли промежуточный уровень (ETL) для миграции из старого приложения?

2. Как организовать минимальный даунтайм

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

3. Команда и ответственность

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

4. Что можно перенести технически

• Бизнес-логику, если она формализована;
• Базу данных, если формат — SQL или структурированный NoSQL;
• Дизайн — как референс, но с модернизацией под платформы;
• Клиентские аккаунты и авторизацию — если используемые системы поддерживают OAuth2, OpenID.

Грамотная миграция решает одновременно вопрос безопасности (новый код, отказ от “дырущихся” уязвимостей), UX (новый интерфейс) и способа масштабироваться (например, переход с хостинга на облачную платформу).