Подрядчик бросил проект: как забрать код и доделать продукт

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

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

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

• Домен: доступ к аккаунту регистратора. Это самый болезненный актив — с потерей домена теряются адрес бизнеса, почта и весь наработанный SEO.
• Код: доступ к git-репозиторию (GitHub/GitLab/Bitbucket) или, минимум, полный архив исходников с историей.
• Сервер и хостинг: панель управления, SSH-доступы, привязанная почта.
• База данных: реквизиты подключения и свежий дамп.
• Сторонние сервисы: платёжный агрегатор, почтовые сервисы, аналитика, API-ключи интеграций.
• Пароли и секреты: файл конфигурации (.env) актуального окружения — без него код может просто не запуститься.

Дальше нужен честный ответ на вопрос «что здесь на самом деле сделано». Заявленные «95% готовности» на практике могут означать что угодно: от «осталось причесать мелочи» до «работает только демо-сценарий на тестовых данных». Проверить это самостоятельно заказчик без технического бэкграунда не может — нужен независимый аудит кода.

Аудит отвечает на конкретные вопросы: запускается ли проект по инструкции (и есть ли инструкция вообще), какой стек и насколько он живой, нет ли секретов прямо в коде, есть ли тесты, сколько техдолга и где. Как проходит такая проверка, мы подробно разбирали в статье про аудит кода после фрилансера или студии. Результат аудита — не «код плохой/хороший», а картина для решения: объём достроенного, объём переделок и риски.

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

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

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

И отдельно — прозрачность процесса: еженедельные демо, код в вашем репозитории после каждого спринта, понятное ТЗ с критериями приёмки. Как составить такое ТЗ, мы разбирали отдельно. Подрядчику, который работает прозрачно, эти условия только удобны; сопротивление им — ранний сигнал будущих проблем.