Договор на разработку сайта: что проверить перед подписанием
Договор на сайт обычно читают по диагонали: цена совпала, срок устроил, подписали. Неприятное всплывает позже. Выясняется, что правки бесплатны только два круга, техзадания в договоре нет вообще, а домен зарегистрирован на подрядчика. Разбираем по-человечески, что в таком договоре действительно важно, какие пункты чаще всего становятся поводом для спора и на что смотреть, если текст прислал не ваш юрист.
Зачем договор, если и так всё понятно
Главное заблуждение звучит так: договор нужен, чтобы потом судиться. На практике до суда доходят единицы, а вот до неприятного разговора «мы так не договаривались» - почти каждый второй проект без нормальных бумаг. Поэтому договор полезен не как оружие, а как способ доспорить заранее, пока обе стороны настроены дружелюбно и ещё никто не потратил ни рубля.
Смотрите, что происходит без него. На старте вы обсуждаете проект голосом или в переписке, и у каждого в голове складывается своя картинка. Вы думаете, что «сайт» - это пять страниц, тексты, картинки, подключённая аналитика и форма, которая шлёт заявки в почту. Подрядчик думает, что тексты даёте вы, фотографии вы, а аналитика идёт отдельной услугой. Никто не врёт. Просто эти две картинки никто не сверил, и они разъезжаются ровно в тот момент, когда проект надо сдавать.
Второй сюжет: люди меняются. Менеджер, с которым вы «обо всём договорились в чате», уходит из студии. У вас увольняется маркетолог, который вёл проект. Всё, что жило только в переписке и в чьей-то памяти, испаряется вместе с этими людьми. Написанный документ - единственное, что переживает смену состава.
Обязательный минимум в договоре
Не нужно двадцати страниц юридического текста. Нужно, чтобы в документе были закрыты шесть вещей. Если хотя бы одна из них отсутствует, вы подписываете не договор, а намерение подружиться.
Формулировка «исполнитель обязуется разработать сайт» не значит ничего. Нужен состав: сколько страниц или экранов, какие блоки, какие функции, кто пишет тексты, кто даёт фото, какие интеграции подключаются. Обычно это выносят в приложение с техзаданием, а в договоре ставят ссылку на него. Без ТЗ спорить бесполезно: доказать, что «в сайт входил личный кабинет», нечем. Как собрать нормальное ТЗ, мы разбирали в отдельном материале про техзадание на сайт.
Срок «30 рабочих дней» без точки отсчёта не работает. С какого дня он идёт: с подписания, с получения предоплаты или с момента, когда вы прислали материалы? Обычно верно последнее, и это нормально, но должно быть написано. Дальше срок лучше разбить на этапы: прототип, дизайн, вёрстка и программирование, наполнение, запуск. Тогда видно, где именно проект встал, а не «мы почти закончили» третью неделю подряд.
Помимо суммы и графика платежей важен список того, что оплачивается отдельно: хостинг, домен, платные шаблоны и модули, лицензии на шрифты, фотографии со стоков, эквайринг, услуги копирайтера. Каждый из этих пунктов сам по себе небольшой, но вместе они умеют превращаться в неприятный сюрприз к моменту запуска.
Самое горячее место. Нужны две цифры и одно определение: сколько кругов правок входит в цену на каждом этапе, в какой срок вы даёте обратную связь и что вообще считается правкой. Поменять заголовок и переставить блок - правка. Заменить всю концепцию дизайна после утверждения прототипа - новая работа. Если это не разделено, вы либо бесконечно правите бесплатно, либо платите за каждую запятую.
Как передаётся результат, сколько у вас есть дней на проверку, в каком виде фиксируются замечания и что происходит, если вы молчите. Пункт про «принято автоматически через N дней» встречается часто и сам по себе не злодейство, но N должно быть человеческим, а не двумя днями. Что смотреть при приёмке - подробно в статье про приёмку сайта у подрядчика.
Кому принадлежит дизайн и код после оплаты, что именно передаётся (макеты, исходники, доступы к панели, хостингу, домену, аналитике) и в какой момент. Пункт скучный ровно до того дня, когда вы решите сменить подрядчика.
Ещё одна деталь, которую почти всегда забывают: обязанности заказчика. Да, у вас они тоже есть. Прислать материалы, назначить одного ответственного человека, отвечать на вопросы в разумный срок, согласовывать этапы. Хороший подрядчик впишет это не чтобы прикрыться, а потому что половина сорванных сроков в вебе - это не «программист медленный», а месяц ожидания текстов и фотографий от клиента.
Пункты, из-за которых потом спорят
Реальные конфликты кучкуются вокруг четырёх тем, и каждая лечится одним абзацем, написанным до начала работ.
Сроки и чья вина в просрочке. Классика: проект встал, потому что клиент две недели не присылал прайс, а потом удивился, что запуск сдвинулся. В договоре стоит явно написать, что сроки продлеваются на время ожидания материалов и согласований со стороны заказчика. Это защищает обе стороны: подрядчика от несправедливой претензии, а вас от подрядчика, который прикрывает собственную медлительность общими словами. Про то, из чего вообще складывается длительность проекта, у нас есть разбор сроков разработки сайта.
Где заканчивается правка и начинается новая работа. Граница проходит по утверждённому этапу. Пока прототип не утверждён, менять структуру - нормальная часть процесса. После утверждения прототипа просьба «а давайте вообще по-другому» стоит денег и времени, и это честно. Плохо не то, что за это берут деньги, а то, что об этом не предупредили заранее.
Что происходит после запуска. Гарантийный срок на ошибки и платная поддержка - это разные вещи, и их важно различать. Ошибка вёрстки, найденная через неделю после сдачи, чинится бесплатно: это брак. Просьба добавить новый раздел через месяц - это уже работа. Хорошо, когда в договоре написан и срок гарантии, и порядок дальнейшей поддержки: часы, стоимость, скорость реакции.
Расторжение. Самый неприятный, но самый нужный пункт. Что будет, если вы решите остановить проект на середине или подрядчик поймёт, что не тянет. Обычно логика такая: оплачиваются фактически выполненные и принятые этапы, наработки по ним передаются заказчику. Если такого пункта нет, каждая сторона будет считать по-своему, и заканчивается это плохо для всех.
Права на сайт: код, дизайн, домен и доступы
Здесь простое правило: по умолчанию исключительные права на созданные дизайн и код остаются у автора, то есть у подрядчика, если в договоре прямо не написано обратное. Многие заказчики уверены, что раз заплатили, то всё автоматически их. Это не так, и об этом узнают в самый неподходящий момент.
Что должно быть написано явно. Первое: после полной оплаты исключительные права на результат переходят к заказчику. Второе: подрядчик передаёт исходники - макеты дизайна, файлы проекта, доступы к административной панели, хостингу, домену, счётчикам аналитики. Третье: подрядчик может показывать работу в портфолио, если вы не против. Последнее выглядит мелочью, но лучше решить это сразу, чем потом обнаружить свой закрытый корпоративный проект в чужом кейсе.
Отдельная тема - домен. Он должен быть зарегистрирован на вас или вашу компанию, а не на студию, не на конкретного разработчика и не на «нашего админа Сашу». То же с хостингом и с аккаунтом в почтовом сервисе. Когда всё это оформлено на подрядчика, вы формально не владеете собственным адресом в интернете, и любая ссора превращается в заложническую ситуацию. Мы разбирали это подробно в материале про то, кому принадлежит сайт и доступы.
И ещё один слой, о котором вспоминают редко: чужие материалы внутри вашего сайта. Платный шаблон, коммерческий шрифт, фотографии со стока, готовый модуль - у всего этого есть лицензия, и она бывает ограничена одним проектом или одним доменом. Нормальная практика - написать в договоре, что подрядчик использует материалы, права на использование которых у него есть, и передаёт вам подтверждение лицензий. Иначе претензия за картинку прилетит вам, а не тому, кто её поставил на страницу.
Красные флаги в договоре подрядчика
Сразу оговорюсь: ни один из этих пунктов не означает, что перед вами мошенники. Часто это просто старый шаблон, который никто не перечитывал. Но каждый - повод задать вопрос до подписания.
Нет техзадания и никакого приложения с составом работ. Самый крупный флаг. Предмет описан одной строкой, состав не зафиксирован. Такой договор не защищает никого: ни вас, ни подрядчика.
Стопроцентная предоплата без разбивки на этапы. Аванс - это нормально, работать полностью бесплатно никто не обязан. Ненормально, когда вся сумма уходит вперёд и у вас не остаётся ни одного рычага. Разумный компромисс: оплата по этапам, каждый закрывается принятым результатом.
Молчаливая приёмка за два-три дня. Если по договору результат считается принятым, когда вы не ответили за 48 часов, то один отпуск или один аврал - и вы приняли сайт, который толком не смотрели.
Обещания результата в трафике и заявках. Пункт вроде «исполнитель гарантирует рост заявок» или «выведем в топ-3 за два месяца» - это не забота о вас, а красный флаг. Ни одна честная студия, включая нас, не может гарантировать количество заявок или позиции в поиске: это зависит от рынка, спроса, конкуренции, цены вашего продукта и работы ваших же менеджеров с обращениями. Гарантировать можно объём работ, сроки и качество исполнения. Всё, что обещано сверх этого, обычно написано на бумаге ровно затем, чтобы вы подписали.
Штрафы только в одну сторону. Если для вас за просрочку оплаты предусмотрена пеня, а за срыв срока подрядчиком не предусмотрено ничего, документ перекошен. Симметрия здесь важнее размера штрафа.
Частые вопросы
Нужен ли договор, если сайт делает знакомый фрилансер?
Нужен, и как раз с фрилансером он часто важнее. У студии есть репутация и поток клиентов, ей невыгодно скандалить, а у частного исполнителя таких сдерживающих механизмов меньше. Достаточно короткого документа на пару страниц: состав работ, этапы, сроки, цена и передача прав и доступов.
Что важнее: договор или техзадание?
Это разные инструменты, и по-настоящему работают они только вместе. Договор описывает отношения: деньги, сроки, ответственность, права. Техзадание описывает продукт: что именно должно получиться. Договор без ТЗ не даёт понять, что вы купили. ТЗ без договора не даёт понять, что происходит, если его не выполнили.
Можно ли работать по счёту или оферте, без подписания бумаг?
Да, оплаченный счёт и публичная оферта на сайте исполнителя тоже создают договорные отношения. Вопрос в другом: описан ли там состав работ и порядок приёмки. Если оферта общая, на три абзаца, то формально договор есть, а спорить всё равно не о чем. В этом случае просите приложить хотя бы согласованное по почте техзадание.
Может ли подрядчик гарантировать заявки с сайта?
Нет. Количество заявок зависит от спроса, трафика, конкуренции, цены вашего предложения и того, как быстро вы отвечаете обратившимся. Подрядчик отвечает за объём и качество работ, за сроки и за исправление собственных ошибок. Обещание конкретного числа заявок или позиции в поиске - маркетинговый приём, а не обязательство, которое реально выполняют.
На кого регистрировать домен?
На вас или вашу компанию. Подрядчик может помочь с регистрацией и настройкой, но администратором домена должны быть вы. Так вы в любой момент можете сменить исполнителя, хостинг или почту, не выпрашивая доступ у того, с кем, возможно, уже не разговариваете.
Короткий вывод
Договор на сайт - это не защита от подрядчика, а способ заранее договориться о том, о чём иначе поспорите потом. Минимум, который должен быть в документе: предмет с техзаданием приложением, этапы и точка отсчёта сроков, цена и список того, что оплачивается отдельно, количество кругов правок с определением правки, порядок приёмки и передача прав, исходников и доступов. Отдельно проверьте домен: он должен быть оформлен на вас. И держите в голове простое правило: обещать можно объём, сроки и качество работ, а вот гарантий по заявкам, трафику и позициям в поиске честный подрядчик не даёт, потому что они от него не зависят.
Пришлите договор, посмотрим вместе
APST делает сайты в Воронеже с 2005 года и работает по договору с техзаданием приложением, этапами и передачей прав после оплаты. Если у вас на руках договор от другого подрядчика и есть сомнения - пришлите, посмотрим и честно скажем, чего в нём не хватает. Это бесплатно и ни к чему вас не обязывает.
Обсудить проект