← Блог · Мобильные приложения
Переделать приложение: когда хватит доработки, а когда его пишут заново
Приложение уже есть — но открывать его стыдно: тормозит, разработчик отвечает раз в месяц, а от любой правки всё сыпется ещё сильнее. Разбираем, по каким признакам решают переделать приложение заново, а когда хватит обычной доработки, и сколько стоит каждый вариант.
Приложение уже есть.
И оно раздражает. Не вас — тех, кто открывает его в сторе и закрывает через десять секунд, потому что экран не грузится, а кнопка записи промахивается мимо пальца. Если вы ещё выбираете, делать приложение вообще или хватит сайта, — вам в другую статью, здесь для тех, у кого оно уже стоит и работает через раз.
Тормозит — не значит «переписывайте всё»
Первая мысль обычно такая: раз глючит — значит, написано плохо, значит, переписать с нуля. Мысль понятная. И отчасти верная: если каждая мелкая правка тянет за собой три новых бага, а оценка «на два дня» превращается в две недели — код действительно в критическом состоянии.
Но у этой логики есть слабое место. По разбору сценариев рефакторинга против переписывания с нуля большинство жалоб на старое приложение — это не приговор архитектуре, а устаревшие библиотеки, медленный процесс разработки у текущего подрядчика и баги, которые вылезают из-за отсутствия тестов. Все три чинятся без переписывания одной строки бизнес-логики. Переписывание оправдано, когда объём работ небольшой или когда узкое место — производительность, которую не вытащить оптимизацией. Не тогда, когда просто раздражает. похожие разборы — в кейсах
Три причины, из-за которых приложение просят переделать
На практике их обычно три, и лечатся они по-разному.
- Стек устарел физически. Приложение написано на Cordova или PhoneGap — фреймворках, чью коммерческую поддержку Adobe официально свернула. Cordova формально жива и получает точечные обновления, но разрыв между её версиями и требованиями свежих iOS и Android растёт с каждым годом. Для такого приложения доработка — это латание дыр на тонущей лодке, разумнее мигрировать на Flutter, React Native или Capacitor.
- Бизнес вырос, а архитектура — нет. Приложение делали под одну задачу — витрину или запись, а сейчас нужны интеграция с кассой, кабинет франчайзи, несколько ролей пользователей. Это не повод переписывать всё: обычно хватает доработки конкретных модулей, если код в остальном не рассыпается от прикосновения.
- Исходники и доступы потеряны. Подрядчик пропал, а исходного кода на руках нет — только рабочая сборка в сторе. Тут сначала восстанавливают то, что можно: бизнес-логику реверс-инжинирят из поведения живого приложения, а не сочиняют заново с нуля. С ИИ-инструментами это делается быстрее, чем пять лет назад, но без доступа к аккаунту разработчика в сторах не обойтись — если его тоже нет, разговор начинается не с кода, а с юриста.
Когда вместо переписывания хватит конструктора
Не каждый случай решается заказной разработкой. Если приложение — простая витрина без сложной логики: расписание, каталог, форма записи, — а весь бюджет уходит на поддержку кода, который три года никто не открывал, честный вариант не переписывать всё заново, а перенести функционал на no-code конструктор или PWA.
Звучит странно от компании, которая зарабатывает на разработке. Зато честно: если задачу закрывает готовая платформа за месяц вместо полугода кастомной разработки, дороже не значит лучше. Разница проверяется одним вопросом — есть ли в приложении своя бизнес-логика: расчёт баллов лояльности, интеграция с кассой или CRM, разные роли пользователей. Если есть — конструктор её не вытянет, и разговор снова про переписывание или доработку. Если нет — витрину дешевле и быстрее собрать заново на готовой платформе, чем чинить чужой legacy-код ради формы записи на пять полей.
Барбершоп, который два года боялся трогать своё приложение
Сеть барбершопов в Екатеринбурге заказала приложение с записью на стрижку ещё в 2023-м. Фрилансер сделал, сдал, пропал — обычная история. Приложение работало, пока в 2024 году Google не остановил старый протокол push-уведомлений: записи продолжали приходить, а напоминания клиентам — нет. Никто в компании не понимал, можно ли это починить, потому что никто не видел исходный код и не знал, на чьём аккаунте оформлена публикация в Google Play.
А чинить оказалось не так страшно, как выглядело со стороны. Доступ к консоли разработчика восстановили через саппорт Google по документам о владении бизнесом — без исходников это заняло дольше, чем сама правка. Бизнес-логику записи собрали заново, глядя на то, как работает старое приложение, а не откуда взялся код. На полное решение ушло три недели, из которых две — на переписку с поддержкой, а не на разработку.
Что проверить самому, прежде чем звонить подрядчику
Часть диагностики можно сделать за один вечер, без разработчика.
- Откройте отчёты о сбоях в Google Play Console и App Store Connect — если они у вас есть. Посмотрите, растёт ли число крашей после последних обновлений или держится ровно. Если доступа нет ни у кого в компании, это уже первый и самый важный факт для разговора с подрядчиком: без него вы не узнаете о проблеме, пока не позвонит клиент.
- Спросите у текущего или прошлого исполнителя акт передачи исключительных прав на код — не акт сдачи работ, а именно передачу прав. Отдельный документ, отдельная формулировка. Если такого акта нет, юридически код может не принадлежать вам, даже если оплата прошла полностью и вы годами считали приложение своим.
- Сравните скорость правок за последний год: если задача «на два дня» стабильно занимает две недели, а после каждого релиза растёт число новых багов вместо старых — это симптом технического долга, а не разовое невезение с исполнителем.
- Проверьте, на чём написано приложение. Если в переписке с разработчиком мелькают Cordova или PhoneGap — заложите миграцию на современный стек в план, даже если сейчас всё работает: разрыв с требованиями сторов растёт каждый год, а не только в момент, когда что-то ломается.
- Установите текущую версию на живой телефон и пройдите путь клиента от регистрации до оплаты или записи. Разработчики тестируют по своему сценарию, а ломается обычно там, где реальный пользователь делает что-то, чего никто не предусмотрел.
Где решение без ваших данных невозможно
Дальше — честно. По общей статье нельзя сказать, чинить ваш код или переписывать: это видно только изнутри конкретного проекта. Рефакторинг фрагмента, который выглядит несложным снаружи, иногда стоит дороже переписывания, если внутри пять лет накапливались костыли поверх костылей. А полное переписывание, которое кажется радикальным решением, в вашем случае может свестись к паре недель работы, если бизнес-логика простая, а проблема — правда только в устаревшем стеке.
Свежая разработка похожего по сложности MVP на рынке сейчас стоит от 2 до 4–5 млн рублей за 3–4 месяца — и полное переписывание по деньгам и срокам обычно недалеко от этой вилки, просто потому что это и есть новая разработка, только с оглядкой на старое приложение. Точечная доработка стоит в разы меньше, но её цена сильно зависит от состояния кода, которое без аудита не оценить на глаз.
На разборе смотрим ваше текущее приложение — код, доступы, отчёты о сбоях — и говорим прямо: чинить или переписывать, и во сколько это встанет именно вам. разбор вашего приложения