Технический долг после аудита: что исправлять первым и сколько это стоит

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

Почему сейчас

Счёт приходит позже

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

Проблема не новая, но она растёт. В опросе Stack Overflow 2024 года технический долг стал главным раздражителем разработчиков: его назвали 62% опрошенных. В опросе Sonar за январь 2026 года на ИИ пришлось 42% кода в коммитах, и только 48% разработчиков сказали, что всегда его проверяют. ИИ позволяет команде построить за год то, на что раньше уходило три, и так же быстро накопить трёхлетний долг.

Покупатели это заметили. В опросе KPMG о сделках в технологиях 66% участников сделок обсуждают технический долг при планировании, но лишь 33% действительно его проверяют. Разницу оплачивают после закрытия. Наш партнёрский бренд The Structure собрал цифры рынка, цены проверки и цены исправления в статье Technical debt in 2026: demand, review prices and repair costs (на английском).

Карта

Аудит, который ведёт к плану

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

Мы начинаем с одной из трёх точек:

• Наша проверка перед приёмом проекта, когда код приходит от другого подрядчика. Аудит перед приёмом стоит от $3 000, а сам порядок описан в статье Как принять сайт или приложение от другого разработчика.
• Аудит того, чем компания на самом деле владеет: домены, аккаунты, лицензии, доступы и код. Он часто находит долг, который никто не считал. От $2 000.
• Отчёт внешнего проверяющего, в том числе технический дью-дилиджеснс перед продажей. Мы берём его находки как есть и превращаем в порядок работ.

Аудит стоит столько, сколько с ним можно сделать.

Порядок

Что мы исправляем первым

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

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

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

Наши случаи

Три погашенных долга и один на очереди

Наш собственный сайт, Laravel с 7 на 13. peretz.agency надёжно работал на Laravel 7 и PHP 7, но обе версии давно остались без поддержки. Laravel не позволяет перепрыгивать через основные версии, поэтому переезд означал шесть отдельных миграций, по одной версии за раз, на закрытой копии сайта и с записанным путём назад. Это заняло около трёх дней разработки. Две ловушки, которые уронили бы весь сайт, были пойманы на копии, а не на боевом сервере. Подробно в статье Шесть версий Laravel за три дня.

The Structure, со статического генератора на Laravel. Живой сайт, который собирал скрипт на Python, нужно было превратить в приложение на Laravel так, чтобы посетитель ничего не заметил. Мы поставили одно правило: каждая страница должна отдавать те же байты, что и раньше, с автоматической проверкой каждого адреса и одной командой для возврата. Различия в округлении, JSON и экранировании между двумя языками всплыли на проверке и были исправлены до переключения. Этот случай описан в статье Как мы перевели The Structure на Laravel, не изменив ни одного байта.

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

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

Без переписывания

Почему мы редко начинаем с нуля

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

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

Бизнес работает, а долг тем временем уменьшается.

Перед продажей

Когда работу проверит покупатель

Покупатели относятся к этому серьёзно: в исследовании SRS Acquiom 51% американских инвестиционных банкиров назвали техническую проверку самой тяжёлой частью дью-дилиджеснс. Когда компания готовится к продаже, порядок смещается к тому, что прочитает проверяющий со стороны покупателя: безопасность и доступы, владение кодом и аккаунтами, работа с данными и всё, что умеют запускать только основатели. Исправленная проблема с подтверждениями читается в комнате данных совсем иначе, чем та же проблема, найденная покупателем.

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

Команда

Европейские инженеры, цены ниже американских

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

Европейское качество не обязано стоить по американским ценам. Американские агентства чаще всего берут $100 до $149 в час за любого, кого поставят на проект. У нас за $100 в час работает старший инженер, а инженер среднего уровня стоит $55 до $75, и для исправления долга этого часто достаточно.

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

Европейское качество не обязано стоить по американским ценам.

Цены

Сколько стоит погасить долг

Аудит самая маленькая часть счёта. Наши текущие цены:

• Аудит перед приёмом чужого кода: от $3 000.
• Аудит цифрового владения (домены, аккаунты, лицензии, доступы): от $2 000, крупный бизнес от $3 000.
• Технический дью-дилиджеснс: сессия $1 500, полная проверка от $7 500.
• Само исправление оцениваем по аудиту, фиксированным проектом или по часам: около $100 в час за старшего инженера и $55 до $75 там, где хватает инженера среднего уровня.
• После исправления поддержка от $1 000 в месяц держит версии свежими, чтобы долг не вырос снова. Для команды, которой нужно техническое руководство без найма на полный день, внешний CTO от $3 500 в месяц.

Для сравнения: опубликованные программы спасения рабочей кодовой базы по фиксированной цене обычно стоят от $25 000 до $50 000, а для сложных продуктов доходят до $100 000. Наш собственный переезд с Laravel 7 на 13 занял около трёх дней разработки, потому что порядок работ был определён до первой изменённой строки.

FAQ

Источники

• Developer Survey 2024 results, Stack Overflow
• State of Code Developer Survey, Sonar, January 2026
• The AI blind spot in M&A, KPMG
• M&A Due Diligence Study 2026, SRS Acquiom