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

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

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

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

Как обычно приходят к пропаже подрядчика

«Срочно нужен MVP, договор потом». Потом не наступает. Когда исполнитель исчезает, выясняется, что даже понять степень готовности некому: нет стенда, нет списка задач, нет демо сценариев.

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

«Приёмка — это когда скажет, что готово». Без промежуточных актов и критериев «готово» превращается в бесконечный туман. Спор о том, что входило в объём, начинается именно тогда, когда связь уже оборвалась.

Грабли, которые усиливают ущерб

• Предоплата без этапов и без права приостановить работы при срыве сроков.
• Отсутствие корпоративных аккаунтов: всё на личной почте исполнителя.
• Нет резервных копий репозитория и документации по развёртыванию.
• Секреты и ключи API только у подрядчика — смена команды блокирует прод.
• Устные изменения объёма без фиксации — потом невозможно доказать границы работ.

Как выходить из ситуации и не повторить её

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

Инвентаризация активов. Что есть: репозитории, домены, серверы, дизайн, переписка с ТЗ, доступы к магазинам, ключи платёжных и-SMS-сервисов. Что можно восстановить через регистратора и хостера. Что придётся признать потерянным.

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

Новый контур владения. Репозиторий компании, окружения компании, секреты в корпоративном-storage, доступ по ролям. Подрядчик получает права на время работ, а не-«владеет проектом».

Переоценка объёма. Честный аудит кодовой базы: что можно оставить, что дешевле переписать, какие дыры в безопасности и качестве. Обещание-«доделаем за две недели то, что бросили» редко сбывается.

Этапность и приёмка. Короткие итерации с демо, критерии готовности, оплата за принятые этапы. Это защищает обе стороны и делает исчезновение заметным раньше, чем сгорит весь бюджет.

Когда нужна управляемая разработка-«с нуля или с руин», полезна рамка-разработки приложений и ПО-—-не как лозунг, а как модель с договором, доступами заказчика и промежуточной приёмкой.

Что требовать в договоре в следующий раз

1. Репозиторий и конвейер сборки на стороне заказчика с первого дня.
2. Список учётных записей и правило передачи при смене команды.
3. Этапы, демо, критерии приёмки, удержание части оплаты до сдачи.
4. Обязанность документировать запуск и ключевые решения.
5. Понятный процесс изменения объёма-—-иначе-«ещё одну маленькую правку» съест весь срок.

Итог для собственника

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

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

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

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

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

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

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

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