До подписания договора на разработку проверьте пять вещей: что именно названо результатом работ (перечнем, а не «сделаем сайт»); кому и когда переходят права на код — письменно; как принимаются этапы и где граница между правкой и новой задачей; что покрывает гарантийный период после запуска и сколько он длится; на чьих аккаунтах домен, серверы и репозиторий. Если хотя бы на один из этих вопросов подрядчик отвечает уклончиво — это риск, который потом стоит дороже всей экономии.
Содержание
Почему «мы всё сделаем» — не гарантия
На встречах все подрядчики обещают одно и то же: сделаем быстро, качественно и с душой. Различия начинаются в документах: что из обещанного зафиксировано так, что на него можно сослаться через три месяца, когда останутся только переписка и договор.
Договор — это не признак недоверия, а инструмент против недопонимания.
Договор — это не признак недоверия, а инструмент против недопонимания, и защищает он обе стороны: заказчика — от «это не входило», исполнителя — от бесконечных «ещё чуть-чуть поправьте». Показательный маркер: добросовестный подрядчик сам настаивает на подробном договоре, потому что работает по нему каждый день.
Предмет договора: что именно вам сделают
Самый частый источник конфликтов — предмет договора из одной строки: «разработка сайта». Под этой строкой каждая сторона видит своё, и выясняется это на приёмке.
Туда же — формат передачи: код в каком репозитории, документация в каком виде, доступы к каким системам. «Передать проект» без расшифровки — та же строка-ловушка.
Права на код и доступы — только письменно
Блок, в котором ошибки самые дорогие. Проверьте, что в договоре явно написано:
- Права на код и материалы переходят заказчику — с момента оплаты этапа, а не «после завершения всех работ» (иначе при споре на полпути вы остаётесь без всего).
- Репозиторий создаётся в организации заказчика, а не у подрядчика «с доступом для вас».
- Домен, хостинг и ключевые сервисы регистрируются на аккаунты заказчика — смена подрядчика не должна требовать «переезда».
- Список передаваемых доступов зафиксирован: репозиторий, серверы, домен, базы, интеграционные ключи, аналитика.
- Прописан сценарий расторжения: что передаётся, в какой срок, что считается оплаченным.
Приёмка по этапам, а не «в конце»
Договор с единственной приёмкой в финале означает, что о проблемах вы узнаете тогда, когда исправлять их дороже всего. Нормальная схема — этапы с демонстрацией работающего результата и актом по каждому.
Что фиксировать:
- Длительность этапа и что в него входит.
- Форма демонстрации (живое демо, не скриншоты).
- Срок, за который заказчик даёт обратную связь (да, это обязанность заказчика — без неё «подрядчик сорвал срок» часто означает «мы месяц не отвечали»).
- И главное — граница между правкой по замечанию и новой задачей.
Формула границы простая:
Правка по замечанию
- Несоответствие зафиксированному описанию
- Исправляется в рамках этапа
Новая задача
- Новое пожелание
- Оценивается отдельно
Обе стороны знают правила заранее, и приёмка перестаёт быть торгом.
Гарантийный период и что после запуска
Запуск — не конец отношений: что-то обязательно всплывёт на реальных пользователях. Проверьте три вещи:
Гарантийный период
- Что зафиксировать
- Сколько времени после запуска ошибки исправляются бесплатно и что считается ошибкой: несоответствие зафиксированному поведению — да; «давайте кнопку повыше» — нет
Поддержка после гарантии
- Что зафиксировать
- Формат и условия — абонемент, почасовая, по заявкам; сроки реакции на критичные и некритичные проблемы
Разница между гарантией и развитием
- Что зафиксировать
- Гарантия чинит обещанное, развитие добавляет новое
Красные флаги в договоре
- Предоплата 100% до начала работ — у добросовестных студий оплата привязана к этапам.
- Права на код «после полной оплаты всего проекта» — промежуточные этапы вы оплатили, а права на них не получили.
- Отказ фиксировать список «не входит» — значит, границы будут рисоваться в момент спора.
- Нет пункта о расторжении и передаче наработок — выйти из отношений без потерь не получится.
- Шаблонный договор без упоминания специфики вашего проекта — его писали не про вас.
- «Гарантируем позиции в поиске / топ в ChatGPT» в договоре на разработку — обещание того, что не контролируется исполнителем.
Как это устроено в InterLAB
Для прозрачности — наш собственный порядок, который можно использовать как образец вопросов к любому подрядчику:
Репозиторий
- Как у нас
- Создаётся в организации заказчика с первого коммита
Ритм работы
- Как у нас
- Спринты по две недели с живым демо в конце каждого
Оплата
- Как у нас
- Привязана к этапам (для MVP-спринта — 50% на старте, 50% на релизе)
Список «что не входит в этап»
- Как у нас
- Фиксируется на брифе
Передача
- Как у нас
- После запуска передаются документация и все доступы
NDA
- Как у нас
- Подписываем по вашему или нашему шаблону
Эти пункты мы готовы проговорить и показать в договоре до старта — собственно, по этой статье и проверяйте.
