Договор на разработку сайта: 10 пунктов, которые защитят заказчика

Что должно быть в договоре на разработку сайта: обязательные разделы

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

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

Права на сайт и исходный код: как не остаться без своего проекта

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

Ключевой момент здесь — привязка передачи прав к моменту полной оплаты. Обычно права переходят после подписания акта и внесения финального платежа, но формулировки бывают разными. Проверьте, что в договоре прописано: какие исходники передаются (архивы проекта, база данных, админка), какие доступы (хостинг, домен, почта, аккаунты в сервисах) и в какие сроки. Практика показывает, что именно доступы и исходники становятся камнем преткновения при конфликтах. Если подрядчик исчезает, а доступы не переданы, восстановить проект сложно. Выбор подрядчика для SEO после запуска тоже требует внимания к договору, и тут полезно свериться с как выбрать SEO-агентство.

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

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

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

Этапы и платежи: почему нельзя платить 100% вперед

Типичная схема оплаты в договоре на разработку сайта выглядит как аванс 30–50%, затем промежуточные платежи по факту сдачи этапов и финальный расчет после запуска и подписания акта. Полная предоплата оставляет заказчика без рычагов влияния: если исполнитель пропадет или сорвет сроки, возврат денег придется выбивать через суд месяцами. Поэтапная оплата работает иначе: каждый платеж привязан к конкретному результату, который вы принимаете и проверяете. Это дисциплинирует подрядчика и позволяет расторгнуть договор с минимальными потерями, если качество вас не устраивает.

На каждом этапе вы платите за измеримый результат: за прототип, за дизайн-концепцию, за верстку и программирование, за тестирование. Приемка должна быть зафиксирована в договоре через акт или чек-лист, а не через устное «все ок». Если в договоре предусмотрены этапы разработки, это же правило работает и для редизайна, где без четкого планирования и договорных обязательств легко утонуть в правках, про этапы редизайна сайта мы писали отдельно. Закрывающий платеж стоит делать не меньше 20–30%: он мотивирует подрядчика довести проект до продакшена и исправить баги после запуска.

Приемка работ: как проверить, что сайт действительно готов

Приемка это не момент подписания акта, а полноценный этап с чек-листом и фиксированными сроками. В договоре пропишите, что после уведомления о готовности у вас есть 10–15 рабочих дней на тестирование. Проверяйте всё: формы, корзину, адаптивность, скорость загрузки, поведение кнопок на реальных устройствах. Мы обычно советуем клиентам прогнать сайт через Яндекс.Вебмастер и PageSpeed Insights, а не полагаться на «глазомер». Зафиксируйте в договоре, что акт подписывается только после устранения всех замечаний, иначе формально сайт считается сданным, и доказывать обратное потом сложно.

Нашли баги? Составьте письменный список с приоритетами: критичные ошибки блокируют запуск, незначительные можно занести в отдельный список на доработку. Важно, чтобы в договоре был пункт о гарантийном периоде, обычно это 6–12 месяцев, в течение которых разработчик исправляет ошибки бесплатно. Уточните, что входит в гарантию: только баги или ещё и мелкие правки вёрстки. Чтобы избежать споров, требования к будущему продвижению лучше зафиксировать заранее, например, составьте бриф на SEO-продвижение ещё на этапе договора, тогда и структура сайта, и технические требования будут заложены правильно с самого старта.

Ответственность и штрафы: что будет, если подрядчик сорвет сроки

Неустойка за просрочку это единственный пункт, который реально дисциплинирует подрядчика. Адекватная цифра 0,1% от суммы договора за каждый день задержки, при этом лучше привязать ее к стоимости неоплаченного этапа, а не ко всему контракту. Если подрядчик предлагает «символические» 0,01% или вообще отказывается включать неустойку, это повод насторожиться: значит, срыв сроков у него в практике случается регулярно. Верхняя граница разумного 0,5% в день, выше суды часто снижают по статье 333 ГК РФ, так что закладывать космические проценты смысла мало.

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

Чек-лист: 10 пунктов договора, которые нужно проверить перед подписанием

Когда доходит до подписания, начинается самое скучное и одновременно важное: чтение договора. Мы обычно советуем заказчикам не полагаться на «среднюю» форму, а проверить десять конкретных пунктов. Это занимает час, зато потом не приходится разбираться в судах, кто кому что должен.

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

• Точное описание работ: перечень страниц, функций, интеграций и требований к дизайну, чтобы не оказалось, что «лендинг» это одна страница, а вы ждали пять.
• Сроки и промежуточные дедлайны: даты этапов, а не только финального релиза, иначе непонятно, когда подрядчик отстает от графика.
• Порядок изменения требований: фиксация правок через техзадание и допсоглашение, а не через голосовые сообщения в мессенджере.
• Условия оплаты: график платежей по этапам, а не 100% предоплата, иначе теряется рычаг влияния на качество.
• Права на результат: явная передача исключительных прав на сайт, дизайн и исходный код после полной оплаты, без этого сайт формально принадлежит разработчику.
• Ответственность сторон: реальные штрафы за просрочку, а не символические 0,01% годовых, которые никто не взыщет.

Типичные ошибки заказчиков при заключении договора на сайт

Самая частая ошибка в том, что договор на разработку сайта подписывают, не читая приложения. Исполнитель прикладывает к договору общие условия, смету и календарный план, а заказчик смотрит только на итоговую сумму. Потом выясняется, что в смете нет интеграции с CRM, а «дизайн-концепция» включает только один вариант главной страницы. Мы в Cinar сталкивались с проектами, где заказчик приходил уже после подписания такого договора и удивлялся, почему правки считаются дополнительными работами. Выход один: читать договор вместе с приложениями, а если чего-то не понимаете, требовать расшифровки формулировок до подписания.

Вторая системная ошибка, отсутствие четкого ТЗ. Устные договорённости вроде «сделайте красиво и современно» не работают, когда через месяц вы получаете сайт, который совсем не то, что вы себе представляли. Формулировки «в соответствии с техническим заданием» в договоре бесполезны, если самого ТЗ нет или оно написано общими фразами. В нашей практике был случай, когда в ТЗ значилось «лендинг для услуги», а подрядчик сделал одностраничник без формы заявки, потому что она не была прописана явно. Договор без детального ТЗ и спецификации это лотерея, где выигрывает исполнитель. Права на код тоже часто забывают прописать, а потом вы не можете сменить подрядчика, потому что исходники остаются у предыдущего разработчика. И финальный штрих, подписание акта без проверки и игнорирование гарантийных обязательств, после этого все баги приходится оплачивать отдельно. Cinar как раз решает такие задачи, когда заказчик уже обжёгся на невнятном договоре и хочет выстроить отношения с подрядчиком прозрачно, с нормальной защитой своих интересов.

Часто задаваемые вопросы

Константин Крючков

Senior SEO-специалист

Подписаться на ТГ