Договор на разработку сайта: на что обратить внимание

Договор на разработку сайта — не формальность, а единственный инструмент, который защищает обе стороны, когда что-то идет не по плану. Большинство конфликтов между заказчиками и исполнителями возникают из-за расплывчатых формулировок, а не из-за злого умысла. Разберем, какие разделы должны быть в документе и какие пункты стоит проверить особенно внимательно.

Зачем нужен договор и что он должен решать

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

Хороший договор отвечает на пять базовых вопросов. Что именно будет сделано и в каком виде? Когда и по каким этапам? Сколько это стоит и как оплачивается? Что произойдет, если одна из сторон не выполнит обязательства? И кому будет принадлежать результат? Все остальное — детали, которые уточняют эти пять тем.

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

Материал носит общий информационный характер и не заменяет консультацию юриста: для крупных или нестандартных проектов договор лучше показать специалисту.

Предмет договора и объем работ

Это самый важный раздел, и он же чаще всего написан слишком коротко: «разработка сайта». Такая формулировка допускает любые трактовки. Исполнитель считает, что сделал все, а заказчик ожидал совсем другого.

Чтобы избежать этого, подробное описание вынесите в приложение — техническое задание. В нем должны быть:

• перечень страниц и разделов с их назначением;
• описание функций: формы, каталог, фильтры, личный кабинет, оплата, интеграции;
• платформа и используемые технологии;
• требования к адаптации под мобильные устройства и браузеры;
• требования к скорости и безопасности;
• что именно входит в наполнение: тексты, фотографии, перенос данных со старого сайта;
• что в проект не входит. Явный список исключений защищает от споров не меньше, чем список обязанностей.

Если проект большой, техническое задание согласуется и подписывается отдельно, а изменения в него вносятся только письменно, по дополнительному соглашению. Это важно, потому что пожелания в ходе работы неизбежны, и их нужно отделять от первоначального объема.

Этапы, сроки и порядок приемки

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

Продумайте, что происходит при задержках. Часто сроки срываются по вине заказчика: он слишком долго согласует макеты или не присылает материалы. Хороший договор это учитывает и устанавливает, что сроки исполнителя продлеваются на время задержки с вашей стороны, а также определяет разумное время на согласование каждого этапа. Это справедливо для обеих сторон, и честный исполнитель такой пункт воспримет нормально.

Приемка работ

Опишите, как принимаются результаты. Исполнитель уведомляет о готовности, заказчик в оговоренный срок проверяет работу и либо подписывает акт, либо отправляет замечания. Важно зафиксировать, что считается существенным недостатком, как исправляются замечания и что будет, если заказчик молчит. Без этого молчание может считаться приемкой, и вы потеряете право на претензии.

Практический совет: приложите к договору чек-лист приемки: что проверяется, на каких устройствах и браузерах. Тогда приемка превращается из спора в простую сверку по списку.

Стоимость и порядок оплаты

В этом разделе должно быть ясно, какая сумма, за что и когда выплачивается. Для типовых проектов принята оплата по этапам. Аванс в начале показывает серьезность намерений и покрывает первые затраты, следующие платежи привязаны к сдаче этапов, а последний — к окончательной приемке и запуску. Это защищает обе стороны: исполнитель не работает бесплатно, а заказчик не платит за невыполненное.

Уточните следующее:

1. Фиксированная ли цена или оплата по часам. Для проектов с понятным объемом лучше фиксированная, для исследовательских и развивающихся — почасовая с ограничением.
2. Включены ли налоги и с какой системой налогообложения работает исполнитель.
3. Как оплачиваются дополнительные работы: по каким ставкам и после какого согласования.
4. Какие расходы несет заказчик отдельно: лицензии, стоковые изображения, платные модули, домен, хостинг.
5. Что происходит с авансом, если проект остановлен по инициативе одной из сторон.

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

Правки, изменения и дополнительные работы

В ходе проекта почти всегда появляются новые идеи. Если порядок обращения с ними не прописан, они превращаются в источник конфликтов. В одном случае исполнитель молча делает лишнее и потом выставляет счет, в другом — отказывается от любых изменений.

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

Права на результат: дизайн, код, тексты

Один из самых недооцененных разделов. По закону права на результат интеллектуальной деятельности не передаются автоматически только потому, что вы заплатили. Нужно прямо прописать, что исключительные права или лицензия переходят к заказчику, в каком объеме, на какой срок и после какого события, обычно после полной оплаты.

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

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

Ответственность, гарантии и поддержка

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

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

Отдельно пропишите ответственность за контент и данные. Заказчик гарантирует, что имеет право использовать переданные материалы. Обе стороны обязуются защищать персональные данные, а доступы к системам передаются и хранятся безопасно. Хорошо, если после запуска предусмотрен отдельный договор на техническую поддержку, где описаны объем, время реакции и стоимость.

Конфиденциальность, доступы и расторжение

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

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

• Проверьте реквизиты сторон и полномочия подписанта.
• Убедитесь, что все приложения пронумерованы и подписаны.
• Сохраните переписку: она подтверждает согласования, если договор молчит.
• Не подписывайте документ, содержащий пустые поля или ссылки на несуществующие приложения.

Что делать, если возник спор

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

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

Вывод

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