Договор на разработку сайта в малом и среднем бизнесе слишком часто подписывают как формальность на двух страницах: «Исполнитель обязуется разработать корпоративный сайт за 20 рабочих дней, Заказчик обязуется оплатить N рублей». Проблемы начинаются через три недели: выясняется, что мобильная версия, перенос старых товаров, настройка форм по 152-ФЗ и подключение СДЭК в понимание подрядчика не входили и требуют доплаты, а исходный код после сдачи остаётся на чужом сервере без передачи исключительных прав.
В студии ДАКОД мы строим договорную документацию на стыке главы 37 ГК РФ (подряд), части четвёртой ГК РФ (интеллектуальные права на программы для ЭВМ, базы данных и дизайн) и инженерной практики испытаний по ПМИ. Ниже разбираем, из каких частей должен состоять безопасный договор на разработку сайта или веб-сервиса в 2026 году и какие формулировки нужно проверить до внесения предоплаты.
Из каких документов состоит защищённый договор на разработку сайта
Сам по себе текст договора определяет только общие правила игры: порядок расчётов, ответственность за просрочку, конфиденциальность и переход прав. Предмет разработки — что именно должно появиться на экране, как должны работать кнопки и за какое время открываться страницы — невозможно и опасно описывать внутри общих статей договора. Для этого к договору обязательно прикладываются три оцифрованных документа1:
| Документ в комплекте | За что отвечает юридически и технически | Что происходит, если этого документа нет |
|---|---|---|
| Основной текст договора | Предмет, порядок сдачи-приёмки (ст. 720 ГК РФ), отчуждение исключительных прав (ст. 1296 ГК РФ), гарантийный срок (12 месяцев), реквизиты и подписи | Не определены момент перехода прав на код, сроки мотивированного отказа от приёмки и границы бесплатной гарантии |
| Приложение № 1. Календарный план и график этапов оплаты | Разбивает проект на проверяемые этапы (прототип и 3 концепта дизайна → вёрстка и программирование → тестирование и выкладка) с точной суммой и датой каждого этапа | Заказчик платит крупный аванс без промежуточных контрольных точек и не может отследить просрочку до самого конца срока |
| Приложение № 2. Техническое задание (ТЗ) | Исчерпывающий перечень шаблонов страниц, блоков, ролей, интеграций (1С, CRM, оплата, доставка), требований к скорости, адаптиву и 152-ФЗ | Любая не названная прямо функция объявляется подрядчиком «дополнительной работой за отдельную плату», а суд при споре не может установить предмет договора |
| Приложение № 3. Программа и методика испытаний (ПМИ) | Таблица конкретных тест-кейсов («действие → ожидаемый результат»), по которой проверяется готовность сайта перед подписанием финального акта | Приёмка превращается в бесконечный спор вкусов: «мне кажется, фильтр работает неудобно» против «мы всё сделали» |
Твёрдая или приблизительная смета: как защититься от роста цены по ходу проекта
По статье 709 Гражданского кодекса РФ цена работы в договоре подряда может быть твёрдой или приблизительной. Причём закон содержит важную презумпцию (п. 4 ст. 709 ГК РФ): при отсутствии других указаний в договоре цена работы считается твёрдой, и подрядчик не вправе требовать её увеличения, даже если в момент заключения договора нельзя было предусмотреть полный объём работ или расходы выросли.
Недобросовестные исполнители обходят эту норму двумя фразами в шаблоне договора, которые нужно вычёркивать при согласовании:
- Оговорка об «ориентировочной оценке часов» (Time & Material без верхнего потолка). Если в договоре написано, что итоговая стоимость определяется по фактическим трудозатратам разработчика из расчёта N рублей в час, бюджет проекта полностью выходит из-под контроля заказчика. Для малого бизнеса безопасна только твёрдая фиксированная смета (Fixed Price) по утверждённому ТЗ.
- Размытая граница между «правкой по ТЗ» и «новой доработкой». Чтобы не спорить на этапе дизайна, мы в ДАКОД закрепляем в договоре правило трёх концептов дизайна до старта вёрстки: сначала показываем три разных визуальных решения на реальной структуре вашего сайта, вы выбираете одно, мы доводим его по вашим замечаниям до утверждения — и только после этого начинаем писать код. Любые исправления в рамках согласованного ТЗ входят в фиксированную смету.
Исключительные права на сайт, дизайн и код: почему фразы «исполнитель сдаёт сайт» недостаточно
Сайт с точки зрения части четвёртой ГК РФ — это составной объект интеллектуальной собственности, включающий программу для ЭВМ (исходный код фронтенда и бэкенда), базу данных, графический дизайн и текстовые материалы (ст. 1259, 1260, 1261 ГК РФ). Согласно статье 1296 ГК РФ, если программа для ЭВМ или база данных создана по договору, предметом которого было её создание (по заказу), исключительное право принадлежит заказчику, если договором между подрядчиком и заказчиком не предусмотрено иное2.
Однако на практике здесь кроются три юридические и технические ловушки:
- Права на дизайн, иллюстрации и тексты при смешанном договоре. Если договор сформулирован не как договор авторского заказа / создания программы по заказу (ст. 1296 ГК РФ), а как общий подряд или оказание услуг (ст. 1297 ГК РФ), либо если в шаблоне студии мелким шрифтом указано, что заказчику передаётся лишь «неисключительная лицензия на использование», то владелец бизнеса не имеет права самостоятельно модифицировать сайт или передать его доработку другой команде без согласия первого подрядчика. В договоре должно быть прямо прописано отчуждение исключительных прав в полном объёме на все результаты интеллектуальной деятельности (код, дизайн-макеты в Figma, вёрстку, структуру БД, написанные тексты) с момента полной оплаты этапа или проекта.
- Лицензионная чистота шрифтов, фотографий и плагинов. Если дизайнер использовал в макете коммерческий шрифт без веб-лицензии на домен заказчика или взял фотографии из интернета без лицензии, претензию и иск от правообладателя (от 10 000 до 5 000 000 ₽ по ст. 1301 ГК РФ) получит владелец домена. В нашем договоре закреплена гарантия исполнителя об отсутствии нарушений прав третьих лиц: мы используем только шрифты со свободной коммерческой лицензией (OFL) или лицензией клиента и реальные фотографии бизнеса.
- Фактическая передача исходников и root-доступов вместе с актом. Юридическое право бесполезно, если сайт заперт в аккаунте разработчика. В ДАКОД финальный акт сдачи-приёмки всегда сопровождается передачей архива исходного кода (или репозитория), дампов базы данных, макетов и полных административных доступов (SSH/SFTP, панель хостинга, админка CMS, кабинеты Вебмастера и Метрики) на учётные записи самого заказчика.
Как составить ТЗ на разработку сайта, чтобы оно работало в суде и в продакшне
Для сайтов малого и среднего бизнеса не нужен стостраничный бюрократический том по ГОСТ 34.602-20203, который никто не читает. Хорошее ТЗ занимает 6–15 страниц и описывает проект без двусмысленностей в шести обязательных разделах:
- 1. Карта сайта и перечень уникальных шаблонов. Точный список URL или типов страниц (главная, каталог, карточка товара/услуги, страница города, статья блога, контакты, политика ПДн, страница 404) с составом блоков на каждом шаблоне.
- 2. Функциональные сценарии и калькуляторы. Формулы расчёта (как в калькуляторе объёма бассейна в кейсе «КЕНАЗ» или подборе специальности в «КЭСИ Дистант»), логика фильтрации, корзины и ролей в личном кабинете.
- 3. Внешние интеграции и формат обмена. Куда и в каком виде уходят заявки (в Telegram, на почту, в CRM с передачей
utm_*иreferrer), как работает API доставки СДЭК, онлайн-эквайринг или синхронизация с 1С. - 4. Стек технологий и возможности админ-панели. На чём собирается проект (WordPress, NetCat, 1С-Битрикс или чистый код на Astro / React + Fastify) и какие именно поля (цены, товары, статьи, телефоны, фото) сотрудник заказчика должен редактировать самостоятельно без программиста.
- 5. Нефункциональные требования: адаптив, скорость и SEO-база. Корректное отображение на ширинах экрана от 375 px до 1440+ px без горизонтального скролла, сохранение старых URL через 301-редиректы при редизайне, микроразметка Schema.org, чистая карта
sitemap.xmlи зелёная зона Core Web Vitals. - 6. Требования закона (152-ФЗ и отраслевые нормы). Локализация шрифтов и баз данных на серверах в РФ, страница политики обработки ПДн и отдельного согласия, неотмеченные чекбоксы в формах, cookie-баннер с блокировкой счётчиков до согласия (а для школ и клиник — специальные обязательные разделы).
Приёмка сайта по ПМИ: как превратить сдачу проекта в понятный чек-лист
Программа и методика испытаний (ПМИ) — это таблица конкретных проверок, составленная по принципам ГОСТ 19.301-794 на обычном человеческом языке. Вместо того чтобы на созвоне спорить, «готов сайт или ещё нет», заказчик и разработчик открывают таблицу ПМИ и проходят её пункт за пунктом на тестовом стенде:
| Код теста | Что проверяется (действие проверяющего) | Критерий успешного прохождения (ожидаемый результат) | Отметка |
|---|---|---|---|
| ПМИ-01 | Открыть главную страницу, каталог и карточку товара на смартфоне (ширина 375 px) и десктопе (1440 px) | Горизонтальная прокрутка отсутствует, шапка не перекрывает заголовок H1, все кнопки и ссылки кликабельны | Пройден |
| ПМИ-02 | Попробовать отправить форму заявки без отметки чекбокса согласия на обработку ПДн | Форма не отправляется, поле подсвечивается; при отмеченном чекбоксе заявка приходит в CRM / Telegram с указанием страницы и UTM-меток | Пройден |
| ПМИ-03 | Открыть сайт в режиме инкогнито и проверить сетевые запросы до нажатия кнопки в cookie-баннере | Запросы к зарубежным доменам (Google Fonts, reCAPTCHA) отсутствуют; Яндекс Метрика инициализируется после согласия | Пройден |
| ПМИ-04 | Изменить цену товара и телефон в админ-панели CMS по приложенной инструкции администратора | Изменения сразу отображаются на витрине сайта без участия разработчика и без поломки вёрстки | Пройден |
| ПМИ-05 | Запустить проверку домена во встроенном SEO-аудиторе и аудиторе 152-ФЗ | Все страницы из карты сайта отдают код 200 OK, дублей title / H1 и критических нарушений 152-ФЗ нет | Пройден |
Для крупных веб-сервисов и платформ (таких как «Агрегатор Архивов» и корпоративный мессенджер Relic Chat) мы автоматизируем ПМИ через браузерные автотесты Playwright в Chromium и WebKit. Но даже для лендинга за 40 000 ₽ или корпоративного сайта за 70 000 ₽ компактная таблица ПМИ на 15–20 пунктов экономит дни нервов и заказчику, и студии: если все пункты таблицы выполнены, акт сдачи-приёмки подписывается в тот же день.
Гарантия 1 год против платной техподдержки: где проходит граница после запуска
Честный договор обязательно разделяет гарантийные обязательства подрядчика (ст. 722, 724 ГК РФ) и платное абонентское сопровождение после запуска. В студии ДАКОД на каждый разработанный сайт, магазин или веб-сервис действует гарантия 12 месяцев по договору (подробный разбор с примерами — в статье «Год гарантии — зачем и как работает»):
- Что чиним бесплатно по гарантии в течение 1 года: любые ошибки в нашем коде, вёрстке, калькуляторах, формах и скриптах интеграции, которые проявились в ходе эксплуатации не по вине заказчика или третьих лиц.
- Что относится к платной поддержке (от 5 000 ₽ в месяц, неиспользованные часы переносятся): создание новых разделов и посадочных страниц, которых не было в исходном ТЗ, регулярное обновление ядра CMS и сторонних плагинов, мониторинг доступности сервера 24/7, ежедневное резервное копирование и восстановление сайта после некорректных правок сторонних маркетологов.
Если вы планируете разработку нового сайта, интернет-магазина или личного кабинета и хотите заранее увидеть прозрачный договор с приложением-ТЗ и фиксированной сметой — выберите нужный формат в разделе услуг ДАКОД или напишите нам в Telegram: за 20 минут разберём вашу задачу, подготовим структуру ТЗ и назовём точную стоимость до подписания договора.
