Доработать или переписать приложение с нуля: как принять решение

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

Почему «переписать с нуля» — почти всегда дорогая ошибка

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

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

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

Когда доработка — правильный выбор

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

• Стек актуален или обновляется без боли (свежие версии Swift/Kotlin, Flutter, React Native, поддерживаемый backend-фреймворк).
• Код читается: есть структура, понятные модули, хотя бы частичная документация.
• Новые функции добавляются без массового переписывания соседних модулей.
• Сборка проекта проходит, CI/CD работает или восстанавливается за пару дней.
• Проблемы — это конкретные баги, медленные экраны или нехватка фич, а не системный развал.

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

Когда переписывание действительно оправдано

Полная или частичная переработка с нуля имеет смысл, когда сходятся несколько факторов:

1. Мёртвый стек. Технология снята с поддержки (например, проект на устаревших нативных API без обновлений, заброшенный гибридный фреймворк). Обновить нельзя — только мигрировать.
2. Стоимость правок растёт нелинейно. Каждая новая фича ломает три старые, а отладка занимает больше времени, чем сама разработка. Это сигнал технического долга, который дешевле списать.
3. Архитектура не масштабируется. Приложение проектировалось под 1000 пользователей, а нужно 500 000. Монолит без разделения слоёв такую нагрузку не вытянет даже после оптимизации.
4. Утрачен контроль над кодом. Нет исходников, нет доступа к репозиторию, ключевой разработчик ушёл и не передал знания.

Важно: даже при переписывании редко стоит трогать всё сразу. Чаще выигрывает гибридный путь — постепенная замена модулей при работающем приложении (strangler-подход), когда старый и новый код сосуществуют, а пользователь не замечает миграции.

Сравнение затрат: доработка против переписывания

Цифры ниже — ориентир по рынку Казахстана на 2026 год для среднего мобильного приложения с backend. Точная смета зависит от объёма функций и состояния кода.

Аудит перед стартом обычно стоит 150 000 – 400 000 ₸ и почти всегда экономит больше, чем стоит: он показывает, какой путь реально дешевле именно для вашего проекта, а не «по ощущениям».

Как принять решение: пошаговый алгоритм

Чтобы не выбирать на эмоциях, мы используем простую последовательность оценки:

1. Технический аудит. Команда смотрит репозиторий, зависимости, архитектуру, метрики падений и скорости. Результат — карта проблемных зон.
2. Оценка бизнес-целей. Что нужно за 6–12 месяцев: пара функций или принципиально другой продукт? Маленькая цель почти всегда = доработка.
3. Расчёт двух смет. Считаем стоимость доработки и стоимость переписывания на одни и те же требования. Сравниваем не только деньги, но и срок выхода обновления к пользователям.
4. Оценка рисков. Что будет с действующими пользователями, отзывами и выручкой во время работ.
5. Решение. Если доработка решает задачу хотя бы на горизонт года — выбираем её. Переписывание — только когда оно дешевле по совокупной стоимости владения.

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

Частые заблуждения, которые ведут к лишним тратам

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

С чего начать в Казахстане

Практичный первый шаг — заказать технический аудит у студии, которая умеет работать с унаследованным кодом, а не только писать с нуля. Applications.kz занимается модернизацией с 2007 года, в портфеле более 300 проектов на рынках Казахстана, ОАЭ и Таиланда. Мы одинаково спокойно и дорабатываем чужой код, и переписываем то, что действительно того требует. Если вы в Алматы, начать удобно со страницы доработки приложений в Алматы или по телефону +7 (707) 928-13-15 — смету по вашему проекту подготовим за 24 часа.

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

Сколько стоит решить, дорабатывать или переписывать?

Само решение принимается по итогам технического аудита, который стоит от 150 000 до 400 000 ₸ в зависимости от размера кодовой базы. Аудит включает разбор архитектуры, зависимостей и метрик, а также две сметы — на доработку и на переписывание. Эта сумма обычно окупается экономией на неверно выбранном пути.

Можно ли переписать приложение по частям, не останавливая работу?

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

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

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

Как понять, что технический долг стал критическим?

Главный признак — нелинейный рост затрат: каждая новая функция занимает всё больше времени, ломает соседние модули, а отладка съедает больше часов, чем сама разработка. Если команда тратит на поддержку больше, чем на развитие, и боится трогать код, — долг достиг уровня, при котором стоит считать смету переписывания.

Сколько времени занимает доработка приложения?

Одна итерация доработки обычно укладывается в 1–6 недель в зависимости от объёма. Точечные правки и обновление зависимостей делаются за дни, добавление крупной функции — за несколько недель. Полное переписывание среднего приложения занимает от 2 до 6 месяцев, поэтому доработка почти всегда даёт результат пользователям значительно быстрее.