Когда речь заходит о договоре на разработку сайта, многие заказчики перекладывают всю ответственность на юриста: «Он посмотрит, там всё стандартно». Однако специфика IT-проектов такова, что юридическая проверка часто ограничивается формальными реквизитами, сроками и суммой. Всё, что касается реального результата — кода, дизайна, доступов и порядка приёмки, — остаётся вне зоны внимания юриста, но именно эти пункты определяют, получите ли вы работающий продукт или набор файлов, которые нельзя использовать.
Ниже — ключевые аспекты, которые юрист, скорее всего, пропустит, но которые критически важны для заказчика.
Техническое задание: не приложение, а часть договора
Юрист проверит, есть ли в договоре ссылка на техническое задание (ТЗ). Он даже может отметить, что ТЗ должно быть подписано обеими сторонами. Но он не будет вчитываться в содержание ТЗ — а зря.
ТЗ — это единственный документ, который фиксирует, что именно вы хотите получить. Если в договоре написано «разработать сайт», а в ТЗ — «создать адаптивный интернет-магазин с интеграцией 1С, личным кабинетом и системой онлайн-оплаты», то именно ТЗ становится критерием приёмки. Без детального ТЗ любые претензии к подрядчику («я думал, будет по-другому») в суде не сработают. Судебная практика исходит из того, что предмет договора должен быть конкретным и согласованным. Поэтому ваша задача — не просто подписать ТЗ, а убедиться, что в нём описаны все функции, интеграции, дизайн-решения и технические требования, которые для вас важны.
Критерии приёмки: что считается «готовым сайтом»
Юрист проверит, что в договоре есть акт сдачи-приёмки. Но он не станет разбираться, как вы будете принимать работу. А это — одно из самых уязвимых мест.
Пропишите в договоре конкретные критерии готовности:
- какие страницы должны быть созданы на сайте,
- какие страницы должны быть заполнены исполнителем,
- куда и какие данные должны отправлять формы,
- какой функционал должен работать,
- как проверяется скорость загрузки,
- как тестируется адаптивность.
В договоре стоит зафиксировать гарантийный период (например, 6 месяцев), в течение которого вы можете выявить баги, и сроки их исправления. Без этого вы рискуете подписать акт и потерять рычаг воздействия на разработчика.
Исходный код и доступы: кто владеет «начинкой» сайта
Это, пожалуй, самый болезненный пункт. Юрист проверит, что в договоре есть раздел об исключительных правах. Но он вряд ли спросит: передаётся ли вам исходный код?
Многие веб-студии и фрилансеры работают на собственных CMS или используют закрытые фреймворки. Если в договоре не прописана обязанность передать исходный код, вы можете получить сайт, который нельзя доработать без обращения к тому же подрядчику. А если он исчезнет или поднимет цены — вы останетесь с «чёрным ящиком». Кроме того, убедитесь, что вам передаются доступы к хостингу, домену, панели администратора, репозиторию (если используется Git), а также документация и инструкции.
В договоре должно быть прямо указано, что разработчик передает все доступы к:
- файлам сайта и базе данных,
- дизайн-макетам,
- административной панели сайта
- панели управления доменным именем (если он его регистрировал)
Ответственность за срыв сроков
Юрист проверит наличие пункта о неустойке. Но он не будет вникать в то, как эта неустойка рассчитывается и что считается просрочкой.
Обратите внимание на формулировку: «0,1% от стоимости работ за каждый день просрочки» — это стандарт. Но если в договоре есть оговорка «при условии, что задержка произошла не по вине заказчика», убедитесь, что ваши обязанности (например, предоставить тексты или доступы) чётко очерчены. Иначе подрядчик может переложить вину на вас.
Правки
Отдельно проверьте раздел о правках. «Мелкая правка» — это миф: любое изменение требует времени.
В договоре должно быть указано
- сколько правок по каждому этапу (макет, разработка, наполнение) входит в стоимость
- как определяется стоимость правки, если она вышла за лимиты договора
- что является правкой, а что исправлением подрядчиком своих же ошибок
Если в договоре не указано, сколько раундов правок входит в стоимость и что считается доработкой (за которую нужно платить отдельно), вы рискуете получить счёт за каждое исправление.
Скрытые расходы: хостинг, домен, сторонние сервисы
Юрист проверит, что в договоре есть цена. Но он не станет выяснять, входит ли в неё оплата хостинга, домена, SSL-сертификата, шрифтов, стоковых изображений и платных плагинов.
Уточните, кто оплачивает хостинг в первый год, что происходит с доменом (он регистрируется на вас или на подрядчика?), включены ли в стоимость лицензии на используемые библиотеки. Если сайт использует open source компоненты, убедитесь, что их лицензии не создают проблем для коммерческого использования. В договоре должно быть условие, что подрядчик гарантирует отсутствие претензий третьих лиц к используемым элементам.
Гарантийная поддержка: что будет после сдачи
Многие договоры заканчиваются актом приёмки. Но что произойдёт, если через месяц сайт «упадёт» или обнаружится уязвимость?
Пропишите гарантийный период (обычно 6–12 месяцев), в течение которого подрядчик бесплатно устраняет ошибки, допущенные по его вине. Уточните, что считается гарантийным случаем, а что — следствием неправильной эксплуатации или внешнего вмешательства. Если гарантия не предусмотрена, вы можете остаться один на один с проблемами уже на следующий день после подписания акта.
Что делать с этими пунктами
Не пытайтесь переписать договор самостоятельно — это работа для юриста. Но перед тем как отдать документ на проверку, составьте список вопросов, которые вы хотите прояснить. Попросите юриста не просто «посмотреть договор», а проверить его на соответствие вашему ТЗ и на наличие механизмов защиты ваших интересов после сдачи проекта. Если юрист не разбирается в IT-специфике, найдите того, кто работает с digital-проектами. Разница в цене несопоставима с риском потерять бюджет и остаться без работающего сайта.
Главное правило: договор на разработку сайта — это не формальность, а инструмент управления проектом. Чем детальнее вы пропишете результат, права, приёмку и ответственность, тем меньше поводов для споров останется у обеих сторон.
