Главное: типовой шаблон договора из интернета обычно решает одну задачу — формально зафиксировать, что стороны о чём-то договорились. А спор потом возникает не из-за отсутствия договора как такового, а из-за того, что в нём нет конкретики: кто и когда принимает работу, кому принадлежит код после оплаты, что считается «готовым сайтом», а что — недоделкой. Ниже разбираем, что должно быть в договоре на разработку сайта, чтобы он реально защищал обе стороны, а не просто существовал для галочки.

Что такое договор на разработку сайта и зачем он нужен

Это соглашение, в котором заказчик и исполнитель фиксируют предмет работы (разработка сайта целиком или отдельных модулей), порядок оплаты, сроки, ответственность и то, что происходит с готовым результатом — кодом, дизайн-макетами, доменом и доступами.

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

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

Договор подряда или оказание услуг: в чём разница

Разработка сайта чаще оформляется как договор подряда (глава 37 ГК РФ), а не как договор оказания услуг (глава 39 ГК РФ) — и разница здесь не формальная.

  • Подряд предполагает материализованный результат: сайт, код, файлы. Исполнитель отвечает именно за результат, а не за процесс. Это даёт заказчику право требовать устранения недостатков и предусматривает приёмку по акту.
  • Оказание услуг — это оплата за процесс (например, консультации, техподдержка, ведение проекта), где не всегда есть материальный результат для приёмки.

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

Кто исполнитель: физлицо, самозанятый, ИП, юрлицо или штатный сотрудник

От статуса исполнителя зависит, кто платит налоги, какие риски несёт заказчик и как оформляется переход прав.

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

Самозанятый (плательщик налога на профессиональный доход). Платит налог сам, заказчику достаточно чека из приложения «Мой налог». Это самый простой в оформлении вариант для разовых или небольших проектов, но у самозанятого есть ограничение по годовому доходу, и если он его превысит в процессе работы над вашим проектом — статус потребует пересмотра.

ИП или юридическое лицо (веб-студия). Налоги платит сама компания или предприниматель, документооборот — стандартный (договор, счёт, акт, при необходимости — счёт-фактура). Обычно это наиболее предсказуемый вариант с точки зрения ответственности: у юрлица есть реквизиты, к нему проще предъявить претензию.

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

Как заключить договор на разработку сайта: пошаговый порядок

  1. Обсуждение задачи и брифинг — фиксация целей, функционала, референсов.
  2. Составление технического задания на основе брифа.
  3. Согласование договора и ТЗ как приложения к нему.
  4. Подписание договора (очно или через ЭДО/электронную подпись).
  5. Внесение предоплаты по согласованной схеме.
  6. Разработка по этапам с промежуточными демонстрациями.
  7. Приёмка каждого этапа или финального результата.
  8. Подписание акта приёмки-передачи и полная оплата.
  9. Передача исходников, доступов к домену, хостингу и админ-панели.

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

Техническое задание — обязательное приложение к договору

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

  • функционал (разделы, формы, интеграции, личный кабинет и т.д.);
  • требования к дизайну (референсы, брендбук, адаптивность);
  • технологический стек, если это принципиально для заказчика;
  • сроки по этапам;
  • критерии приёмки — по каким признакам этап считается выполненным.

Именно последний пункт чаще всего отсутствует в шаблонных ТЗ, а именно он превращает приёмку из спора «нравится / не нравится» в проверку по конкретному списку.

Существенные условия договора: чек-лист

Прежде чем подписывать, проверьте, что в тексте есть:

  • точный предмет договора со ссылкой на ТЗ как на приложение;
  • сроки — не только общий срок, но и сроки по этапам;
  • стоимость и порядок оплаты, включая условия аванса;
  • порядок приёмки и сроки на предъявление замечаний;
  • ответственность сторон за просрочку и некачественный результат;
  • гарантийный срок на сайт и порядок устранения ошибок;
  • пункт о переходе исключительных прав и момент этого перехода;
  • реквизиты доступов, которые передаются заказчику (домен, хостинг, CMS, аналитика);
  • условия конфиденциальности, если проект связан с закрытой информацией;
  • порядок расторжения и возврата средств за неоказанные работы.

Если хотя бы половины этих пунктов нет — договор нуждается в доработке до подписания, а не после.

Стоимость и порядок оплаты работ по разработке сайта

На практике встречаются три схемы:

  • 100% предоплата. Удобна исполнителю, но рискованна для заказчика — деньги отданы, а результата ещё нет. Оправдана только при небольших проектах или высоком доверии к подрядчику.
  • Поэтапная оплата. Наиболее сбалансированный вариант: аванс на старте, оплата по факту приёмки каждого этапа (дизайн, вёрстка, интеграции, финальная сборка).
  • Оплата по факту полной приёмки. Комфортна заказчику, но немногие исполнители готовы работать без аванса на длинных проектах — это стоит обсуждать заранее, а не как ультиматум.

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

Кому принадлежат код, домен и доступы после сдачи

Это один из пунктов, который чаще всего остаётся без внимания — и именно он создаёт самые болезненные споры постфактум.

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

Отдельно стоит зафиксировать:

  • домен должен быть зарегистрирован на имя заказчика с самого начала или переоформлен на него сразу после оплаты — если домен остаётся на аккаунте исполнителя, при конфликте заказчик рискует потерять адрес сайта;
  • доступы к хостингу, CMS, репозиторию кода и аналитике передаются полным комплектом, а не «частично, для ознакомления»;
  • если используются сторонние платные компоненты (плагины, шаблоны, шрифты с ограниченной лицензией), в договоре стоит уточнить, распространяется ли лицензия на заказчика.

Гарантийный срок на сайт и доработки после сдачи

Стоит различать два вида работ после сдачи проекта:

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

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

Акт приёмки выполненных работ: как оформить и что проверить

Акт приёмки-передачи — документ, который фиксирует, что работы выполнены, соответствуют ТЗ и приняты заказчиком. В нём стоит указать:

  • перечень выполненных работ со ссылкой на этапы ТЗ;
  • дату передачи и срок, в течение которого заказчик может предъявить замечания;
  • явное указание, что с момента подписания акта права на результат переходят заказчику (если это не оговорено отдельным пунктом договора);
  • подписи и реквизиты сторон.

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

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

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

Порядок расторжения обычно включает:

  • право заказчика расторгнуть договор при существенной просрочке с возвратом оплаты за невыполненный объём работ;
  • право исполнителя приостановить работу при просрочке оплаты со стороны заказчика;
  • порядок урегулирования — от письменной претензии до обращения в суд, если стороны не смогли договориться.

Отсутствие этого раздела не отменяет ответственность сторон по закону, но сильно усложняет и затягивает процесс, если дело дойдёт до претензии.

Сравнение форматов договора

Формат исполнителяНалоговая нагрузкаКто платит налогиРиски для заказчикаПереход правДокументооборот
Физлицо без статусаНДФЛ + страховые взносыЗаказчик как налоговый агентДополнительная админ. нагрузка, ответственность за удержание налогаТребует отдельного пункта в договореМинимальный, но риск претензий налоговой
СамозанятыйНалог на профессиональный доходИсполнитель самостоятельноОграничение по годовому доходу самозанятого, риск потери статуса в процессе проектаТребует отдельного пункта в договореДоговор + чек из приложения «Мой налог»
ИП / юрлицо (студия)Налоги по своей системе налогообложенияИсполнитель самостоятельноНаименьшие при наличии реквизитов и репутации компанииПрописывается в договоре, обычно чётко регламентированДоговор, счёт, акт, при необходимости счёт-фактура
Штатный сотрудникНДФЛ + взносы работодателяРаботодательРиски минимальны, но нужен трудовой договор и должностная инструкцияПереходит работодателю как на служебное произведениеТрудовой договор, а не гражданско-правовой

Типичные ошибки и красные флаги в чужих договорах

  • Нет конкретных сроков по этапам — только общий срок «до готовности сайта».
  • Отсутствует пункт о переходе исключительных прав или он сформулирован размыто.
  • Домен регистрируется на исполнителя «для удобства».
  • Нет акта приёмки как отдельного документа — приёмка фиксируется перепиской.
  • Критерии готовности сайта не прописаны, вместо этого — общая фраза «в соответствии с пожеланиями заказчика».
  • Штрафные санкции предусмотрены только для одной стороны.
  • Гарантийный срок не упомянут вовсе, либо все правки после сдачи объявлены платными без оговорок.
  • Техническое задание не оформлено как приложение с подписями сторон, а существует «где-то в переписке».

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

Частые вопросы по договору на разработку сайта

Нужно ли заказчику самому оформлять ИП, чтобы заказать разработку сайта?
Нет, заказчиком может выступать физическое лицо, ИП или юридическое лицо — статус заказчика не влияет на форму договора так, как влияет статус исполнителя.
Можно ли расторгнуть договор, если сайт не устраивает по дизайну?
Если недовольство касается субъективных предпочтений, а не несоответствия согласованному в ТЗ дизайн-макету — оснований для одностороннего расторжения без компенсации исполнителю обычно нет. Именно поэтому важно утверждать макеты письменно на каждом этапе.
Кто отвечает, если после сдачи сайт перестал работать из-за хостинга?
Это зависит от того, кто администрирует хостинг после сдачи проекта. Если ответственность за хостинг передана заказчику по акту — это уже вне гарантийных обязательств исполнителя, если иное не прописано отдельно.
Может ли исполнитель использовать разработанный сайт в своём портфолио?
Может, если это отдельно согласовано в договоре — переход исключительных прав к заказчику не всегда автоматически запрещает исполнителю демонстрировать проект как пример работы, но лучше зафиксировать это явно, а не оставлять на усмотрение сторон.
Что делать, если исполнитель пропал, не завершив проект?
Наличие договора с чётко прописанными этапами и оплатой позволяет требовать возврата средств за невыполненный объём работ или обратиться в суд. Без письменного договора доказать факт договорённостей и суммы оплаты значительно сложнее.

Вывод

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

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

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


Чек-лист «Проверка договора перед подписанием» — Проверить договор на разработку сайта до подписания и закрыть ключевые риски 10 шагов, можно внедрить за вечер. Забрать в телеграм-боте.