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

Компания решила сменить подрядчика по сайту. Новая команда просит доступы, и тут выясняются подробности. Домен оформлен на бывшего разработчика. Хостинг оплачивается с его карты. Исходного кода у компании нет, а в договоре одна строчка: «Исполнитель обязуется разработать сайт согласно ТЗ».

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

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

Чаще всего это договор подряда. Его правила описаны в главе 37 Гражданского кодекса. Подрядчик обязуется сделать результат и сдать его, а вы платите за результат: работающий сайт, который соответствует заданию.

Иногда присылают договор оказания услуг (глава 39 ГК). Здесь платят за действия, а не за результат. Для поддержки, продвижения или работы по часам это нормально. Для создания сайта хуже: «услуги оказаны» можно подписать и тогда, когда сайт так и не заработал.

На практике договор на создание сайта почти всегда смешанный. В нём есть подряд и условия о правах на то, что создано: код, дизайн, тексты. Закон такие договоры допускает.

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

Ещё одна деталь. Самое важное часто лежит не в основном тексте, а в приложениях: техническом задании, календарном плане, расчёте стоимости по этапам, форме акта. Читайте их так же внимательно.

Фраза «разработка сайта» в предмете договора почти ничего не значит. Это как заказать «ремонт квартиры» без сметы и плана. Предмет должен ссылаться на документ, где описан результат: страницы, функции, интеграции, требования к скорости и мобильной версии. Обычно это техническое задание, и о том, как его составить, у нас есть отдельная статья про ТЗ на разработку сайта.

Если ТЗ пока нет, это нормально. Тогда первым этапом идёт аналитика и прототип. Прототип — это черновая схема страниц без дизайна. Удобно, когда этот этап оформлен отдельно: вы платите только за него и в любом случае уходите с готовым документом.

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

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

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

Приёмка — момент, когда спорят чаще всего. Хорошо, если в договоре заранее описано, как она проходит.

Акт по каждому этапу. Этап считается сданным, когда вы подписали акт. Так понятно, за что уже заплачено и что уже принято.

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

Мотивированный отказ. Это список конкретных расхождений с ТЗ: «форма не отправляется с телефона», «нет фильтра по цене, описанного в разделе 4». Фраза «нам не нравится» мотивированным отказом не считается.

Один ответственный. Пропишите, кто с вашей стороны принимает работу. Пять писем от пяти руководителей превращаются в пять кругов правок.

Больше всего недоразумений возникает из-за слова «правки». Под ним скрываются три разные вещи.

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

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

Права могут передать вам двумя способами:

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

По Гражданскому кодексу (статья 1296) исключительное право на программу или другое произведение, созданное по заказу, принадлежит заказчику, если договором не предусмотрено иное. Ключевые слова здесь «если не предусмотрено иное»: в договоре подрядчика такое «иное» вполне может быть. Кроме того, у договора напрямую с автором, например с дизайнером-фрилансером, свои правила. Поэтому не полагайтесь на закон по умолчанию, читайте, что написано в вашем договоре.

Есть и формальная тонкость. По статье 1234 ГК договор об отчуждении исключительного права заключается в письменной форме. А если в возмездном договоре нет условия о размере вознаграждения или порядке его определения, договор считается незаключённым. Поэтому обычно прямо пишут, что вознаграждение за передачу прав включено в стоимость работ. Если такой фразы нет, это повод показать договор юристу.

Нормально, если свои типовые наработки и открытые библиотеки подрядчик оставляет за собой, а вам даёт право ими пользоваться. Важно, чтобы это право было бессрочным и позволяло менять код.

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

Права на бумаге мало что дают, если доступы остались у подрядчика. Проверьте, что в договоре сказано, на кого всё оформляется и когда передаётся.

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

Если подрядчик получает доступ к базе с заявками и контактами клиентов, по 152-ФЗ он обрабатывает персональные данные по вашему поручению. Условия такого поручения тоже нужно прописать в договоре.

Когда сайт делают под ключ, передача доступов и документации должна быть отдельным пунктом сдачи проекта, а не жестом доброй воли.

Гарантия и поддержка звучат похоже, но это разные вещи. Их путают так часто, что стоит разобрать обе.

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

Если гарантийный срок не указан, действует общее правило статьи 724 ГК: требования по недостаткам можно предъявить, если они обнаружены в разумный срок, но не позднее двух лет со дня передачи результата. Понятная гарантия в договоре всё равно лучше, чем спор о том, что считать разумным сроком.

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

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

По статье 717 ГК заказчик может отказаться от договора подряда в любой момент до сдачи результата, без объяснения причин. Если договор не говорит иного, придётся оплатить уже выполненную часть работы и возместить подрядчику убытки, но не больше разницы между ценой всей работы и тем, что уже заплачено.

Запишите, что подрядчик передаёт при расторжении и в какой срок: код выполненной части, макеты, доступы, документацию. И проверьте, что ответственность симметрична: если есть неустойка за вашу просрочку оплаты, должна быть и неустойка за просрочку сроков подрядчиком.

Договор на разработку сайта защищает обе стороны, если в нём ясно описаны результат, этапы, приёмка и правки. Самые дорогие ошибки прячутся в разделах о правах и доступах: кому принадлежат код и дизайн, на кого оформлены домен, хостинг и репозиторий. Гарантия и поддержка — разные вещи, и обе стоит прописать.

Прочитайте договор с вопросами «а что будет, если…», отметьте всё непонятное и обязательно покажите текст юристу. Это займёт пару вечеров и сэкономит месяцы споров.