Конструктор договора на разработку сайта (ПО)

1. Предмет договора: что именно должен создать исполнитель

Главный риск начинается с общей фразы «разработка сайта». Для юриста, разработчика и заказчика она может означать разные вещи. Заказчик думает про готовый интернет-магазин с оплатой, личным кабинетом и каталогом. Исполнитель считает, что должен сделать дизайн, верстку и форму заявки. В споре суду придется выяснять, что стороны реально согласовали, и если документы пустые, результат будет непредсказуемым.

Предмет договора должен отвечать на простой вопрос: какой результат появляется в конце и из каких частей он состоит. В договоре лучше прямо написать, создается ли сайт, веб-приложение, модуль ПО, мобильная версия, личный кабинет, CRM-интеграция, интернет-магазин, лендинг или административная панель. Если используется конструктор, готовая CMS или собственная платформа исполнителя, это тоже нужно указать. Сайт на WordPress, Bitrix, Tilda, Laravel, React или закрытой SaaS-платформе — не одно и то же с точки зрения владения, переноса и доработки.

В предмете желательно перечислить:

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

Если нужно разработать именно программу для ЭВМ, а сайт является только интерфейсом к ней, это лучше не скрывать за словом «сайт». Тогда предмет можно сформулировать как «создание программного обеспечения в виде веб-приложения». Такой подход ближе к ст. 1261 ГК РФ и помогает точнее описать права на код.

Чем точнее описан результат разработки, тем меньше риск, что стороны будут спорить не о качестве сайта, а о том, что вообще было заказано.

2. Правовая природа: подряд, услуги, авторский заказ или смешанный договор

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

Для IT-проекта чаще всего подходит смешанный договор по ст. 421 ГК РФ. В нем можно соединить элементы подряда, возмездного оказания услуг, авторского заказа, лицензионного договора и договора об отчуждении исключительного права. Это не усложнение ради юристов, а нормальное отражение реальности: сайт одновременно нужно спроектировать, запрограммировать, протестировать, запустить и юридически передать.

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

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

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

3. Техническое задание: главный документ, а не формальное приложение

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

По ст. 432 ГК РФ договор считается заключенным, если между сторонами достигнуто соглашение по всем существенным условиям. Для договора на разработку сайта существенным на практике становится не только общее название результата, но и его конкретное содержание. Чем сложнее проект, тем подробнее должно быть ТЗ.

Хорошее ТЗ описывает:

• бизнес-цель сайта и роли пользователей;
• структуру страниц и пользовательские сценарии;
• требования к дизайну, адаптивности и браузерам;
• состав интеграций и обмена данными;
• требования к админ-панели, безопасности и резервному копированию.

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

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

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

4. Сроки и этапы: как избежать состояния «почти готово»

В разработке сайта опасна фраза «срок выполнения — по готовности». Для договора подряда ст. 708 ГК РФ предусматривает начальный и конечный сроки выполнения работ, а также допускает промежуточные сроки. Для договора авторского заказа ст. 1289 ГК РФ прямо устанавливает: произведение должно быть передано заказчику в срок, предусмотренный договором; если срок не предусмотрен и не может быть определен, договор не считается заключенным.

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

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

Для дополнительных пожеланий полезен порядок change request. Если заказчик хочет новую функцию, которой нет в ТЗ, стороны оформляют описание изменения, цену и новый срок. Иначе каждая новая идея будет называться «уточнением», а исполнитель будет считать ее отдельной работой.

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

5. Цена и порядок оплаты: что включено, а что оплачивается отдельно

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

Возможны разные модели оплаты. Фиксированная цена подходит для проекта с понятным ТЗ. Почасовая оплата подходит для разработки, где требования уточняются в процессе. Абонентская модель подходит для поддержки и доработок. Комбинированная схема часто самая разумная: фиксированная стоимость за этапы и отдельная ставка за работы вне ТЗ.

Особенно аккуратно нужно оформлять плату за интеллектуальные права. По ст. 1234 ГК РФ при отсутствии в возмездном договоре об отчуждении исключительного права условия о размере вознаграждения или порядке его определения договор считается незаключенным. По ст. 1235 ГК РФ похожее правило действует для возмездного лицензионного договора. Поэтому нельзя ограничиться фразой «права передаются в составе цены», если из договора непонятно, какое вознаграждение за них предусмотрено.

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

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

6. Интеллектуальные права: кому принадлежит код, дизайн и сайт

Раздел о правах — ключевой. По ст. 1296 ГК РФ исключительное право на программу для ЭВМ, базу данных или иное произведение, созданные по заказу, принадлежит заказчику, если договором между подрядчиком или исполнителем и заказчиком не предусмотрено иное. Но эта норма не делает подробный раздел о правах лишним. Наоборот, она показывает, что договор может изменить правило, а значит, формулировки критичны.

Есть важное уточнение: п. 5 ст. 1296 ГК РФ указывает, что правила этой статьи не распространяются на договоры, где подрядчиком или исполнителем является сам автор произведения; в таком случае применяется ст. 1288 ГК РФ об авторском заказе. Поэтому договор со студией и договор с конкретным дизайнером-физическим лицом могут требовать разных формулировок.

Для сайта обычно нужно разделить четыре группы объектов. Первая — специально созданные элементы: уникальный код, дизайн, структура, тексты, графика. Вторая — прежние наработки исполнителя: библиотеки, универсальные модули, заготовки. Третья — сторонние компоненты: CMS, плагины, шрифты, фотографии, open source. Четвертая — материалы заказчика: логотип, товарные карточки, описания, фото продукции.

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

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

В договоре нужно указать способы использования результата: воспроизведение, переработка, доведение до всеобщего сведения, распространение, перевод, модификация, включение в состав сложного объекта, передача третьим лицам. Способы использования перечислены в ст. 1270 ГК РФ. Лицензионный договор не передает исключительное право, что прямо следует из ст. 1233 ГК РФ, поэтому слова «лицензия» и «отчуждение» нельзя использовать как синонимы.

7. Сторонние компоненты, open source и онлайн-конструкторы

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

Если сайт создается на онлайн-конструкторе, нужно ответить на отдельные вопросы. Кто владеет аккаунтом? Можно ли скачать сайт и перенести его на другой сервер? Что будет при неоплате тарифа? Передается ли исходный код или только доступ к панели? Может ли заказчик сменить подрядчика без потери результата? Иногда конструктор — разумный выбор для лендинга, но плохая основа для сложного продукта, который планируют масштабировать.

С open source тоже нельзя быть беспечным. Открытая лицензия не означает отсутствие условий. Ст. 1286.1 ГК РФ регулирует открытую лицензию, но конкретные условия использования часто содержатся в самих лицензиях: MIT, Apache, GPL и других. Одни разрешают коммерческое использование почти свободно, другие требуют сохранения уведомлений или соблюдения более строгих правил. Поэтому исполнитель должен гарантировать, что сторонние компоненты используются законно.

В приложение к договору можно включить реестр компонентов:

• название компонента и его назначение;
• правообладатель или источник;
• тип лицензии или тариф;
• ограничения использования;
• кто оплачивает продление и поддержку.

Судебная практика по сайтам показывает, что суды смотрят не только на внешний вид страниц, но и на код, дизайн, структуру, доказательства заимствования. В постановлении Суда по интеллектуальным правам от 24.08.2022 № С01-1374/2022 по делу № А56-53395/2021 рассматривался спор о копировании сайта, включая дизайн и исходный код. Это хороший пример того, почему договор должен фиксировать происхождение элементов и права на них.

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

Приемка — это юридическая точка, после которой результат считается переданным, а у заказчика появляется обязанность оплатить соответствующий этап, если она еще не исполнена. По ст. 720 ГК РФ заказчик обязан осмотреть и принять результат работы в порядке и сроки, предусмотренные договором, а при обнаружении недостатков заявить о них подрядчику. По ст. 723 ГК РФ при ненадлежащем качестве работы заказчик может требовать устранения недостатков, уменьшения цены или возмещения расходов на исправление, если условия позволяют.

Для сайта нужно заранее определить, как именно проходит проверка. Исполнитель может предоставить ссылку на тестовый стенд, доступ в админ-панель, архив файлов, репозиторий, инструкцию и акт. Заказчик проверяет результат по ТЗ и в установленный срок направляет либо подписанный акт, либо мотивированный отказ. Мотивированный отказ — это не «мне не нравится», а перечень конкретных несоответствий договору, ТЗ или утвержденным макетам.

Ошибки лучше классифицировать:

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

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

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

9. Исходники, доступы, домен и документация

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

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

В такой акт обычно включают:

• исходный код и ссылку на репозиторий;
• дизайн-макеты и графические исходники;
• базу данных или ее выгрузку;
• доступы к серверу, хостингу, CMS, домену и админ-панели;
• инструкции администратора и техническую документацию.

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

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

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

10. Персональные данные, безопасность и законность контента

Если сайт собирает имена, телефоны, email, адреса доставки, данные личного кабинета, заявки, резюме или иную информацию о пользователях, включается Федеральный закон № 152-ФЗ «О персональных данных». В большинстве случаев оператором персональных данных будет заказчик как владелец сайта, но разработчик может получать доступ к данным при настройке, тестировании и поддержке.

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

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

Законность контента — отдельный риск. Фотографии из поиска, чужие иконки, нелицензионный шрифт, скопированные тексты, товарные знаки без разрешения — все это может привести к претензиям. Ст. 1301 ГК РФ предусматривает компенсацию за нарушение исключительного права на произведение, а ст. 1252.1 ГК РФ указывает, что компенсация взыскивается при доказанности факта нарушения, без необходимости доказывать размер убытков.

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

11. Ответственность, гарантия и расторжение

Ответственность в договоре нужна не для угроз, а для управляемости проекта. Ст. 309 ГК РФ закрепляет обязанность исполнять обязательства надлежащим образом, а ст. 310 ГК РФ ограничивает произвольный односторонний отказ, если иное не предусмотрено законом или договором. Для разработки сайта важно заранее определить последствия просрочки, некачественной работы, задержки оплаты и нарушения прав третьих лиц.

Гарантийный срок лучше указать прямо: например, 30, 60 или 90 дней после приемки. В гарантию обычно входят ошибки, вызванные несоответствием результата ТЗ. Не должны автоматически входить новые функции, изменения сторонних API, сбои хостинга, вмешательство другого подрядчика, самостоятельное обновление CMS заказчиком или изменение законодательства. Эти исключения надо прописать, иначе любая новая задача будет называться «багом».

Для расторжения нужно учитывать правовую природу договора. По ст. 717 ГК РФ заказчик по договору подряда может отказаться от исполнения до сдачи результата, оплатив выполненную часть и возместив убытки в установленных пределах. По ст. 782 ГК РФ заказчик вправе отказаться от договора возмездного оказания услуг при оплате фактически понесенных исполнителем расходов, а исполнитель — при полном возмещении убытков заказчику. В смешанном договоре полезно отдельно описать, как расторжение влияет на уже созданные результаты и права.

Если проект прекращается на середине, нужно понять:

• какие этапы считаются выполненными;
• какие суммы возвращаются, а какие остаются у исполнителя;
• передаются ли промежуточные результаты;
• переходят ли права на уже оплаченные материалы;
• удаляются ли доступы и конфиденциальные данные.

Слишком большая неустойка не всегда помогает. Суд вправе снизить ее по ст. 333 ГК РФ, если признает несоразмерной последствиям нарушения. Поэтому лучше устанавливать разумную ответственность и собирать доказательства: переписку, акты, уведомления, задачи в трекере, коммиты, протоколы тестирования.

12. Как пользоваться образцом, шаблоном и конструктором договора

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

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

Судебная практика подтверждает, что формальные слова не заменяют фактическое содержание договора. Постановление Пленума Верховного Суда РФ от 25.12.2018 № 49 ориентирует суды на анализ заключения, толкования и квалификации договора, а также поведения сторон. Постановление Пленума Верховного Суда РФ от 23.04.2019 № 10 разъясняет применение части четвертой ГК РФ, то есть вопросов интеллектуальных прав. Для IT-договоров эти два документа особенно важны: первый помогает понять, что стороны действительно согласовали, второй — кому и в каком объеме принадлежат права.

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

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