Зачем вообще вникать в договор, если есть хороший подрядчик
Логика «мы же с ними уже созвонились, ребята адекватные, зачем читать десять страниц юридического текста» подводит заказчиков регулярно — не потому, что подрядчики массово нечестны, а потому, что на словах и в переписке одно, а споры возникают вокруг того, что записано или не записано в документе. Пока проект идёт гладко, договор никто не открывает. Он становится важен ровно в тот момент, когда что-то пошло не так: сроки сдвинулись, объём работ вырос, а кто виноват и что делать дальше — не очевидно ни одной из сторон. Хороший договор — это не про недоверие к подрядчику, а про то, чтобы у обеих сторон было общее понимание правил игры до того, как начнутся деньги и время. Ниже — пункты, отсутствие или расплывчатая формулировка которых чаще всего оборачивается реальными спорами на практике, и на что стоит обратить внимание заказчику, даже если договор готовит сам подрядчик.
1. Предмет договора и точный объём работ
Формулировка «разработка сайта» — это не предмет договора, а его отсутствие. Под такой фразой можно сдать что угодно: лендинг на конструкторе или интернет-магазин с интеграцией 1С, и формально обязательства будут выполнены. Правильный подход — вынести подробное техническое задание в приложение к договору и сослаться на него в основном тексте как на неотъемлемую часть: количество и структура страниц, список функциональных блоков, интеграции, которые должны быть реализованы. Именно ТЗ, а не общие фразы, становится тем документом, по которому впоследствии проверяется, выполнены обязательства или нет. Если на момент подписания договора детальное ТЗ ещё не готово — а так бывает, если техническое задание разрабатывается уже в рамках проекта, — стоит хотя бы прописать порядок его согласования и срок, до которого приложение должно быть подписано обеими сторонами, чтобы не получилось, что работа идёт, а зафиксированного объёма всё ещё нет.
2. Сроки и этапы с приёмкой каждого этапа
Единый срок «сайт будет готов через 3 месяца» неудобен обеим сторонам: заказчик не понимает, как идёт работа до самого конца, а подрядчик рискует получить претензию сразу за весь объём, если что-то не готово к дедлайну. Разбивка на этапы — прототип, дизайн, вёрстка, программирование, наполнение, тестирование — с отдельным сроком и отдельной приёмкой на каждом позволяет обеим сторонам видеть прогресс и фиксировать промежуточный результат письменно. Если на этапе дизайна заказчик подписал акт, то к вёрстке уже нет смысла возвращаться с вопросом «а почему кнопка не такого цвета» — это экономит время и нервы всем.
3. Порядок оплаты, привязанный к этапам
Стопроцентная предоплата за весь проект — это риск, который заказчик берёт на себя без необходимости: если подрядчик пропадёт или не выполнит работу, вернуть деньги будет гораздо сложнее, чем не заплатить их вперёд. Разумная схема — оплата, привязанная к тем же этапам, что и сроки: например, аванс на старте, платежи по факту приёмки дизайна и вёрстки, финальный расчёт после сдачи готового сайта. Такая структура выгодна и подрядчику — он получает деньги по мере выполнения работы, а не ждёт полной оплаты в конце, рискуя, что заказчик передумает.
4. Права на результат работы
После полной оплаты именно заказчик должен становиться правообладателем сайта — кода, дизайна, текстов, если они писались подрядчиком. Это должно быть прямо прописано, а не подразумеваться по умолчанию: без явного условия о передаче исключительных прав подрядчик формально может остаться автором и в теории ограничивать использование или доработку сайта другой командой в будущем. Отдельно стоит прояснить вопрос платных плагинов, шаблонов и шрифтов — по каким лицензиям они куплены и на кого оформлены, потому что лицензия, купленная на аккаунт подрядчика, может перестать действовать после завершения сотрудничества.
5. Гарантийный период и порядок внесения правок
После сдачи сайта неизбежно всплывают мелкие недочёты, и договор должен заранее разграничивать, что считается багом, который подрядчик исправляет бесплатно в рамках гарантии, а что — новой доработкой, за которую нужно платить отдельно. Без этого разграничения любая просьба заказчика рискует превратиться в спор: заказчик считает, что «форма не отправляется на новом типе устройства» — это баг, а подрядчик — что это новая задача, потому что при сдаче такое устройство не тестировалось. Явно прописанный гарантийный срок (обычно от одного до трёх месяцев) и критерии «что считается ошибкой» снимают этот источник конфликтов заранее.
6. Ответственность сторон и порядок расторжения
Последний, но не менее важный пункт — что происходит, если проект останавливается на середине: по инициативе заказчика, из-за форс-мажора или из-за невыполнения обязательств подрядчиком. Договор должен отвечать на вопросы: остаются ли у заказчика уже оплаченные наработки — макеты, вёрстка, код на текущем этапе; в каком порядке возвращается неотработанный аванс; какая неустойка предусмотрена за срыв сроков каждой из сторон. Отсутствие этого пункта означает, что при досрочном прекращении проекта стороны будут договариваться заново, уже в конфликтной ситуации, без опоры на документ. Отдельно стоит прописать, что происходит с доступами и учётными записями после расторжения — кто и в какой срок обязан передать оставшиеся материалы, исходные файлы макетов, доступы к репозиторию с кодом, если работа велась в системе контроля версий подрядчика.
Хороший договор экономит время и деньги именно тем, что снимает эти вопросы до старта работ, а не оставляет их на потом. Если вы только планируете разработку сайта и хотите начать с чёткого объёма задач, а не с общих формулировок, — начать проект с брифа — удобная точка входа, где сразу фиксируются требования, которые затем ложатся в основу технического задания и договора. Мы в Evaris готовы обсудить условия сотрудничества и показать, как выглядит наш типовой договор с заказчиком.