Кратко: Договор на разработку сайта фиксирует четыре главные вещи: что именно делает подрядчик (предмет и техническое задание), сколько это стоит и как оплачивается, в какие сроки выполняется и кому перейдут права на результат. В договоре обязательно должны быть: предмет со ссылкой на ТЗ, цена и график платежей, сроки по этапам, порядок приёмки, передача исключительных прав на сайт, гарантийный срок, ответственность сторон и условия расторжения. Ниже — разбор каждого пункта простыми словами, таблица-чеклист из 12 позиций и ответы на частые вопросы заказчиков.
Договорённости о разработке сайта часто начинаются с дружеской переписки: «ну сделайте как у конкурента, только красивее, к сентябрю». Пока работа идёт, всё нормально. Проблемы начинаются, когда сайт сдан наполовину, дизайнер ушёл в закат, а доказать, что было согласовано, — нечем. Договор существует именно для этого: он переводит разговоры в конкретные обязательства с ценой, сроками и последствиями за их нарушение.
Этот материал — часть серии для заказчиков. Если вы ещё выбираете исполнителя, начните со статьи о том, как проверить подрядчика перед заказом сайта, и подготовьте исходные данные по чек-листу технического задания — а затем возвращайтесь сюда, чтобы закрепить договорённости на бумаге.
Зачем нужен договор на разработку сайта
Сайт — это услуга с заранее неизвестным результатом: заказчик описывает желания словами, подрядчик превращает их в код, и чем дальше проект движется, тем больше появляется «а можно ещё…». Переписка в мессенджерах и устные договорённости не защищают ни одну из сторон: скриншоты переписки суд, конечно, примет, но доказать по ним объём работ, цену дополнительных правок и согласованные сроки — отдельная и тяжёлая работа.
Договор решает несколько практических задач сразу. Он фиксирует предмет: что именно заказывается и по каким критериям принимается. Он закрепляет цену и порядок расчётов — вы знаете, за что и когда платите, а подрядчик не боится, что оплату «забудут». Он определяет сроки и ответственность за их срыв. Наконец, он отвечает на вопрос, который в момент старта кажется пустяком, а через год после запуска решает судьбу бизнеса: кому принадлежат права на сайт.
Отдельный плюс письменного договора — дисциплина для обеих сторон. Когда у проекта есть график платежей и этапов с датами, исчезает вечное «давайте начнём на следующей неделе». По Гражданскому кодексу РФ договор может быть заключён и устно, но для работы с подрядчиком письменная форма — стандарт именно потому, что она превращает намерения в доказательства.
И наоборот: работа без договора — это всегда ставка на честное слово. Заказчик рискует предоплатой и сроками, подрядчик — бесконечными правками без оплаты. Если исполнитель наотрез отказывается подписывать договор, это само по себе сигнал: прочитайте ещё раз чек-лист проверки подрядчика и подумайте, готовы ли вы доверить ему деньги.
Какой договор заключить: подряд, услуги или оферта
Для разработки сайта используют три основных конструкции, и разница между ними не бюрократическая — она влияет на то, как регулируются сроки и результат.
| Тип договора | Суть | Когда подходит | На что обратить внимание |
|---|---|---|---|
| Договор подряда | Подрядчик обязуется сдать конкретный результат — работающий сайт по ТЗ | Сайт под ключ, фиксированная смета, понятные этапы | Чётко описанный результат и порядок сдачи-приёмки; правила о подряде — ст. 702 ГК РФ |
| Договор возмездного оказания услуг | Оплачивается процесс: часы, работы, участие специалистов | Консультации, доработки, поддержка, аудит | Результат заранее не гарантирован, поэтому ключевые критерии всё равно выносят в ТЗ |
| Договор-оферта | Публичный документ исполнителя: оплатил счёт — принял условия | Конструкторы, шаблонные решения, небольшие заказы | Читайте до оплаты: правки в оферту после старта внести нельзя |
На практике часто встречается смешанный договор: разработка по модели подряда плюс блок услуг по наполнению и настройке. Это нормально — важно лишь, чтобы в документе не было противоречий, к какой части применяются какие правила. Если исполнитель работает как ИП или компания, договор заключается с организацией, а не с частным лицом «по имени Сергей»; если подрядчик — физлицо без статуса, это тоже допустимо, но тогда особенно важны порядок расчётов и налоговые вопросы.
К договору имеет смысл приложить соглашение о конфиденциальности (NDA), если проект затрагивает бизнес-планы, базы клиентов или нишевые идеи. Отдельный большой документ не обязателен — достаточно пункта или одностраничного приложения, запрещающего разглашать коммерческую информацию.
Предмет договора: что именно вы покупаете
Предмет — центральный пункт договора. Формулировка «разработка сайта» не описывает ничего: сайтовые проекты различаются от лендинга на конструкторе до маркетплейса. Правильный предмет звучит конкретно: «разработка корпоративного сайта на WordPress по техническому заданию (Приложение № 1) из 15 страниц, с каталогом продукции и формой заявки, с адаптацией под мобильные устройства».
Техническое задание становится неотъемлемой частью договора — обычно Приложением № 1. Именно ТЗ отвечает на вопросы, которые иначе превращаются в споры: сколько страниц, какая структура, что делает форма заявки, куда приходят уведомления, кто готовит тексты и фотографии, что считается «мобильной версией». Чем детальнее ТЗ, тем меньше пространства для интерпретаций. Если у вас пока нет документа — начните с нашего чек-листа по составлению ТЗ и передайте его подрядчику как основу.
В предмете или приложениях стоит закрепить и техническую базу: на какой CMS строится сайт, на чьём хостинге размещается, кто регистрирует домен. Эти решения влияют на цену и на то, что вы получите на выходе. Сравнить платформы можно по нашему сравнению WordPress, Bitrix и конструкторов, а требования к площадке — в статье про выбор хостинга.
Худший вариант предмета — ссылки на «похожие сайты» без списка требований. Референс полезен как иллюстрация стиля, но в договоре рядом с ним должен стоять конкретный перечень работ: страницы, функциональность, объём контента, критерии готовности. Иначе любая правка превращается в битву интерпретаций.
Цена и порядок оплаты: этапы, авансы и допработы
В договоре должна быть зафиксирована цена — фиксированная смета за весь проект или порядок её расчёта (например, почасовая ставка с оценкой каждого этапа). Фиксированная цена удобнее заказчику: бюджет известен заранее, риск оценки лежит на подрядчике. Почасовая модель гибче при меняющихся требованиях, но требует контроля: вам должны показывать отчёт, на что ушёл каждый час.
Стандартная схема расчётов — поэтапная. Типовой график выглядит так: аванс 30–50% на старте (он закрывает первый этап — прототип и дизайн), платёж после утверждения дизайна и вёрстки, финальный расчёт после приёмки готового сайта. Требование 100% предоплаты — не приговор, но повод насторожиться и запросить обоснование: это скорее исключение, чем норма рынка.
Обязательно пропишите процедуру дополнительных работ, потому что именно здесь рождаются самые болезненные споры. Рабочая схема: любая задача сверх ТЗ оформляется письменно (хотя бы в электронной почте), подрядчик оценивает её срок и стоимость, заказчик подтверждает — и только потом работа выполняется и оплачивается. Без этой процедуры каждый «а добавьте ещё кнопочку» становится полем для торга в самый неудачный момент проекта.
Отдельно проверьте, что входит в цену, а что оплачивается отдельно. Типичные «серые зоны»: домен и хостинг (обычно оплачиваются заказчиком отдельно — ориентиры есть в статье про выбор домена), покупка или продление лицензий на премиум-темы и плагины, копирайтинг, фотографии, настройка рекламы. Понимание полной стоимости проекта даст статья про цены на разработку сайтов в 2026 году — сверяйте с ней любую смету.
Сроки: календарный план и ответственность за просрочку
Срок в договоре — это не одна дата «когда всё будет готово», а календарный план по этапам с привязкой к моменту начала работ. Грамотная формулировка выглядит так: «Срок выполнения каждого этапа — N рабочих дней с момента получения аванса и материалов от Заказчика». Привязка к старту важна: половина задержек возникает из-за того, что проект формально начался, а материалы от заказчика ещё не собраны.
За просрочку обычно назначают неустойку — чаще всего пени в размере 0,1% от стоимости просроченного этапа за каждый день задержки, с разумным потолком (например, не более 10% от цены этапа). Требовать драконовские штрафы бессмысленно: исполнитель либо не подпишет их, либо заложит риск в цену. Неустойка нужна как стимул, а не как источник дохода.
Важно, чтобы ответственность была обоюдной. Если заказчик задержал передачу логотипа, текстов и доступа, срок сдачи сдвигается соразмерно — это нормальная и справедливая оговорка, и хороший подрядчик её обязательно попросит. Сюда же добавляют пункт о форс-мажоре: обстоятельства непреодолимой силы переносят сроки, но не отменяют обязательства.
Ориентир по реалистичным срокам — материал «сколько времени делается сайт»: визитка занимает 2–4 недели, корпоративный сайт 1–2 месяца, интернет-магазин от 2 месяцев. Если исполнитель обещает вдвое быстрее рынка, уточните, за счёт чего достигается скорость, и не пишите в договор сроки, в которые он сам не верит.
Права на сайт: исходный код, домен и доступы
Самый недооценённый блок договора — права на результат. По умолчанию исключительные права на созданное произведение (а сайт и его дизайн — это именно оно, ст. 1270 ГК РФ) переходят заказчику только тогда, когда это прямо прописано в договоре. Правильная формулировка: «Исключительные права на сайт, дизайн и исходный код переходят Заказчику с момента полной оплаты».
Из прав вытекает вопрос доступов. В договоре или приложении стоит перечислить, что передаётся по завершении проекта: доступ к административной панели, файлам сайта, базе данных, хостинг-аккаунту, панели управления доменом, аккаунтам аналитики. Идеальная ситуация для заказчика — когда домен и хостинг с самого начала оформлены на него или его компанию, а подрядчик работает под выданными доступами. Тогда даже в конфликтной ситуации «сайт никуда не денется».
Если подрядчик регистрирует домен на себя, потребуйте пункт о передаче прав на домен заказчику после оплаты — порядок переноса известен любому регистратору. То же с лицензиями: премиум-темы и платные плагины имеют собственные лицензии разработчиков; уточните, на кого они оформляются и продлеваются ли обновления.
И последнее: техническая документация. Просите хотя бы минимальный пакет — список используемых плагинов, пароли от сервисов, инструкцию по типовым операциям. Это не бюрократия, а ваша страховка от ситуации, когда единственный человек, понимающий устройство сайта, «пропал с радарами».
Гарантии: что исправляется бесплатно после сдачи
Гарантийный срок — период, в который подрядчик обязан бесплатно устранять ошибки в рамках согласованного ТЗ. Рыночная практика — от 1 до 6 месяцев в зависимости от сложности проекта. Важно понимать, что гарантируется: баги и несоответствия ТЗ (не работает форма, съезжает вёрстка в конкретном браузере, битые ссылки), а не новые пожелания. «Хотелки» заказчика гарантия не покрывает — они оформляются как дополнительные работы.
В пункте о гарантиях зафиксируйте три вещи: длительность гарантийного срока, срок реакции на обращение (например, критические ошибки исправляются в течение 1–2 рабочих дней) и что считается ошибкой. Хорошо работает формулировка «ошибкой признаётся несоответствие результата ТЗ, выявленное при штатной эксплуатации».
Гарантийное обслуживание — это не то же самое, что поддержка. Гарантия закрывает дефекты вашей версии сайта; поддержка — регулярная работа с сайтом после запуска: обновления, резервные копии, правки контента, мониторинг. Что обычно входит в такое обслуживание и сколько оно стоит — разобрано в статье про поддержку сайта. Если подрядчик предлагает год поддержки в подарок — переводите это в конкретику: какие работы, сколько часов в месяц, что считается вне объёма.
Отдельно стоит запросить передачу знаний: короткая инструкция или час видео, как добавлять новости, менять цены, смотреть заявки. Для клиента это часто ценнее любого документа — сайт становится самостоятельно управляемым.
Приёмка работ: как зафиксировать результат
Порядок приёмки — механизм, который превращает «ну вроде готово» в юридический факт. Рабочая схема: подрядчик уведомляет о готовности этапа и передаёт ссылку на рабочую версию; у заказчика есть 5–7 рабочих дней на проверку; по итогам заказчик подписывает акт либо направляет мотивированный отказ со списком замечаний; подрядчик исправляет, и цикл повторяется.
Формулировка «если заказчик не ответил в течение N дней, работы считаются принятыми» — стандартна и справедлива, но прочитайте её внимательно: молчание не должно автоматически засчитывать вам приёмку этапа, оплаченного авансом, если сроки проверки сорваны по вине исполнителя, не передавшего материал для проверки. Хороший баланс — молчание = приёмка, но только при условии, что подрядчик действительно предоставил всё для проверки.
Проверять этап стоит по чек-листу, а не по общему впечатлению: структура, формы, скорость, мобильная версия, кроссбраузерность. Базовый список для финальной приёмки вынесен в статью о том, как проверить подрядчика — она пригодится и до старта, и на финише. Помните и про общую логику проекта: этапы разработки описаны в материале «Этапы разработки сайта: от брифа до запуска» — приёмка каждого этапа должна подтверждать его результат, а не «примерное направление».
Допишите в договор и порядок расторжения: что происходит, если проект надо остановить. Обычно — уведомление за 10–15 дней, оплата фактически выполненных и принятых работ, передача заказчику всего, что уже сделано (макеты, код, материалы). Это спасает обе стороны от сценария «всё пропало» при разрыве на середине проекта.
Чек-лист: 12 пунктов договора, которые проверяет заказчик
Соберём сказанное в компактную таблицу. Прежде чем подписывать договор, пройдитесь по ней пункт за пунктом — на заполнение уйдёт 15 минут, а сэкономить она может месяцы споров.
| № | Пункт договора | Что проверить | Риск, если пункта нет |
|---|---|---|---|
| 1 | Предмет | Конкретное описание сайта: тип, CMS, объём, ссылка на ТЗ | Споры о том, что вообще заказывалось |
| 2 | Техническое задание | Приложение № 1 с функциональностью и критериями готовности | «Как у конкурента» вместо требований |
| 3 | Цена | Фиксированная смета или порядок расчёта; что входит и не входит | Растущий бюджет без объяснений |
| 4 | Порядок оплаты | Аванс, платежи по этапам, финальный расчёт после приёмки | Требование 100% предоплаты без гарантий |
| 5 | Сроки | План по этапам, дата начала, привязка к авансу и материалам | Бесконечный «почти готово» |
| 6 | Ответственность | Неустойка за просрочку обеих сторон, форс-мажор | Задержку нельзя компенсировать |
| 7 | Допработы | Письменное согласование сверх ТЗ до выполнения | Счёт за «добавленную кнопочку» постфактум |
| 8 | Приёмка | Срок проверки, акт, мотивированный отказ, доработки | Непонятно, когда проект сдан |
| 9 | Права на результат | Переход исключительных прав после оплаты, передача исходников | Сайт фактически принадлежит подрядчику |
| 10 | Домен и доступы | Домен на заказчика, передача всех аккаунтов и паролей | Сайт «заложник» у исполнителя |
| 11 | Гарантии | Гарантийный срок, время реакции, определение ошибки | Каждый баг — за отдельные деньги |
| 12 | Расторжение | Порядок выхода, оплата выполненного, передача материалов | Разрыв проекта = потеря всего |
К этому списку стоит добавить реквизиты сторон и подписи уполномоченных лиц — банально, но именно здесь теряются половина исков: договор подписан человеком, который не имел права представлять компанию. Если договор составляет юрист исполнителя, не стесняйтесь показать его своему — стоимость консультации несопоставима с ценой ошибки.
Частые вопросы о договоре на разработку сайта
Можно ли заказать сайт без договора — по переписке и оплате счёта?
Формально можно: оплата счёта и переписка создают некоторые доказательства отношений. Но при споре вы не сможете доказать согласованный объём, сроки и права на результат. Минимум — обмен подписанными сканами договора или акцепт детальной оферты; лучше — полноценный договор с ТЗ.
Кто платит за составление договора — заказчик или исполнитель?
Обычно договор готовит исполнитель на своём шаблоне и в цену проекта это не выделяется. Если вы просите существенно доработать документ или привлекаете своего юриста — эти расходы на вашей стороне. Обсудите вопрос до начала, а не на этапе подписания.
Нужно ли заверять договор у нотариуса?
Нет, закон этого не требует: подписи обеих сторон достаточно. Нотариус нужен лишь в редких нестандартных ситуациях. Важнее другое: проверьте, что договор подписывает уполномоченное лицо (директор или представитель по доверенности), и сверьте реквизиты.
Подрядчик просит 100% предоплату — это нормально?
Это сигнал к вопросам, а не автоматический отказ. Требуйте обоснования: покупка лицензий и домена, стартовая закупка. Если без предоплаты никак, снижайте риск: короткие этапы, подробное ТЗ, договор с чёткой ответственностью за просрочку и порядок расторжения с возвратом аванса за непереданные работы.
Чем договор отличается от счёта и акта?
Договор — рамочный документ об обязательствах сторон. Счёт — предложение оплатить конкретную сумму (оплата счёта может означать акцепт оферты). Акт — документ о приёмке результата или этапа. Работают они вместе: договор задаёт правила, акты фиксируют выполнение, счета — движение денег.
Работа уже началась, а договора нет. Что делать?
Заключите его сейчас — стороны вольны оформить отношения на любом этапе, а пункт «договор распространяется на работы с даты фактического начала» закроет задним числом уже сделанное. Если исполнитель уклоняется, зафиксируйте текущие договорённости хотя бы письмом по электронной почте с подтверждением ответом.
Вывод: договор — это не бумага, а план Б
Хороший договор на разработку сайта не нуждается в применении — он просто даёт обеим сторонам спокойствие: заказчик знает, за что платит и что получит, подрядчик защищён от бесконечных правок. План действий простой: подготовьте ТЗ по чек-листу, обсудите с исполнителем смету и график, проверьте договор по нашей таблице из 12 пунктов и только потом вносите предоплату.
Если хотите, чтобы весь процесс — от ТЗ до запуска — вёл один подрядчик с прозрачными этапами и договором, посмотрите услуги разработки сайтов и примеры в портфолио, а с вопросами пишите через форму контактов. Договор, который подписывается за день и работает годами, — это наш базовый стандарт работы с заказчиками.
Больше материалов для заказчиков — в блоге delai-sait.ru: там разобраны проверка подрядчика перед стартом, бюджет на разработку в 2026 году и поддержка сайта после запуска — три темы, которые логично читаются вместе с этим договорным чек-листом.
