Как выбрать подрядчика на разработку и не остаться с брошенным проектом

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

Как теряют проект и деньги

Через мою студию не раз проходили клиенты с брошенными проектами. Схема почти всегда одинаковая. Взяли большую предоплату, работали без понятных этапов, весь код держали у себя, доступы к серверу и репозиторию не отдавали. Пока всё шло, вопросов не возникало. А когда исполнитель исчез, выяснилось, что предъявить нечего и вернуть тоже.

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

Красные флаги до договора

Вот что должно насторожить ещё на переговорах, до любых денег.

• Называет цену и срок сразу, не задав вопросов. Адекватный исполнитель сначала выясняет, что именно нужно, а уже потом считает. Мгновенное «сделаю за 50 тысяч за неделю» это либо непонимание задачи, либо приём, чтобы вы заплатили, а дальше пойдут доплаты.
• Нет ни одного проекта, который можно посмотреть. Ссылки на живые работы, репозитории, отзывы реальных клиентов. Если показать нечего или всё под загадочным NDA, это повод насторожиться.
• Просит крупную предоплату вперёд. 70-100 процентов до начала работ это риск. Нормальная практика это разбивка на этапы с оплатой по факту сдачи каждого.
• Уходит от письменной фиксации. «Давайте без лишних бумаг, я же по-человечески». Именно эти люди потом пропадают, потому что спросить с них формально нельзя.
• Один человек на всё. Не всегда плохо, но если это единственный разработчик без подстраховки, то его болезнь, отпуск или пропажа останавливают проект целиком.
• Размытые ответы про код и доступы. Спросите прямо, где будет лежать код и получите ли вы доступы. Мнётся или обещает «отдам в конце» это флаг.

Что обязательно в договоре

Договор нужен даже с проверенным исполнителем. Он защищает обе стороны и заставляет проговорить детали заранее. Вот что в нём должно быть.

1. Техническое задание отдельным документом. Что именно делаем, с экранами, функциями и границами. Без ТЗ спор «это входило или нет» вы проиграете всегда.
2. Этапы, сроки и суммы по каждому. Разбивка на части с оплатой по сдаче. Это ваш главный рычаг: сорвал этап, дальше не платите.
3. Передача прав на код. Прямая формулировка, что исключительные права на результат переходят к вам после оплаты. Иначе формально код принадлежит исполнителю.
4. Порядок передачи доступов и исходников. Что и когда вы получаете: репозиторий, доступы к серверу, базе, документацию.
5. Гарантийный период. Срок, в течение которого баги правят бесплатно. Обычно от одного до трёх месяцев после сдачи.
6. Ответственность за срыв сроков. Штраф или право расторгнуть договор и забрать сделанное. Без этого сроки для исполнителя необязательны.

Код и доступы: чтобы остались у вас

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

Заведите репозиторий на своём аккаунте GitHub или GitLab и дайте разработчику доступ туда, а не наоборот. Тогда весь код с первого дня лежит у вас, и вы видите, что работа реально идёт, по коммитам. Пропал исполнитель, а код на месте, и его подхватит любой другой.

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

Этапы и приёмка по частям

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

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

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

Схемы оплаты без переплаты

Как платить, чтобы и исполнителю было спокойно, и вы не рисковали всей суммой. Собрал варианты.

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

Короткий чек-лист

Перед стартом пробегитесь по пунктам.

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

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