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

1. Что обязательно включить в договор

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

• Предмет договора: точное описание работ (дизайн, верстка, бэкенд, интеграции).
• Deliverables: конечные артефакты (макеты, исходники, установленные модули, доступы).
• Сроки и этапы с приёмкой — критерии и процедура подтверждения работ.
• Оплата: график, условия, акты выполненных работ, налогообложение.
• Права: кто владеет кодом, дизайном, контентом и как передаётся право.
• Гарантии и поддержка: период, SLA, багфикс.
• Порядок изменений, дополнительные работы и стоимость change order.
• Конфиденциальность, безопасность данных, обработка персональных данных.
• Ответственность сторон, форс‑мажор, порядок расторжения и расчётов при досрочном прекращении.
• Процесс эскалации и разрешения споров — арбитраж/медиация.

2. Описание объёма работ и deliverables

Чем конкретнее — тем меньше споров. Формулируйте объём в понятных артефактах и критериях приёмки.

2.1 Примеры deliverables

• Дизайн: прототипы страниц (в Figma/Sketch), финальные адаптивные макеты для разрешений (desktop, tablet, mobile) и гайдлайны по стилю.
• Верстка: HTML/CSS/JS файлы, адаптивная верстка, кроссбраузерная поддержка, оптимизация под Core Web Vitals.
• Backend: настройка CMS (указать версию), интеграция API, авторизация, обработка форм, админ‑панель, миграция данных.
• Интеграции: платёжные системы, CRM, сервисы рассылок, аналитика (Google Analytics/GA4), GTM.
• Тестовая среда и продакшен: описание окружения, инструкции по деплою.
• Документация: README по установке, инструкция для контент‑менеджера, список всех доступов и логинов.

2.2 Как описать функциональность

Используйте user stories и acceptance criteria. Пример: «Как администратор, я хочу иметь возможность создавать новости через CMS с полями: заголовок, картинка, краткое описание, контент; критерий приёмки — запись публикуется и отображается в публичной части по URL /news/{slug} без ошибок». Это снимает двусмысленность.

3. Сроки, этапы, приёмка и тестирование

Разбейте проект на этапы (микро‑milestones) с чёткой приёмкой каждого этапа. Включите протокол приёмки и регламент тестирования.

3.1 Пример этапов

1. Аналитика и ТЗ — 7 рабочих дней.
2. Прототип/UX — 10 рабочих дней.
3. Дизайн ключевых страниц — 14 рабочих дней.
4. Верстка и фронтенд — 10 рабочих дней.
5. Бэкенд и интеграции — 15 рабочих дней.
6. Тестирование, правки, подготовка к запуску — 7 рабочих дней.

3.2 Приёмка и критерии

Опишите процедуру: подрядчик предоставляет пакет артефактов и чек-лист тестов, заказчик в течение N рабочих дней проводит проверку и предоставляет акт приёмки или список замечаний. Если замечаний нет — акт подписывается автоматически по истечении срока.

4. Оплата и финансовые риски

Оплата должна быть привязана к результатам. Типичный подход — предоплата + этапы по результату или почасовая оплата с контрольными точками.

4.1 Примеры схем оплаты

• Фикс‑прайс: 30% предоплата, 40% по завершению дизайна, 30% по сдаче проекта.
• Фикс‑прайс с эскроу: средства на депонировании у третьей стороны, переходятся по этапам.
• Time & Materials: ежемесячные акты и отчёт по часам; лимит бюджета и механизм согласования перерасхода.

4.2 Важные финансовые пункты

• Условия выставления актов и счетов, срок оплаты (обычно 10–30 дней).
• Порядок возврата предоплаты при расторжении и штрафы за просрочку.
• Налоги и ответственность за НДС/УСН — кто выставляет счета и удерживает налог.

5. Права интеллектуальной собственности и исходники

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

5.1 Что передаётся

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

5.2 Формулировки

Пример формулировки: «Подрядчик передаёт Заказчику неисключительные/исключительные права на результат работ в полном объёме после полной оплаты. Под исходниками понимаются: файлы проекта в Figma/Sketch, репозиторий с исходным кодом (git), SQL‑дамп базы, инструкции по деплою». Укажите формат передачи (архив, доступ к репозиторию) и сроки передачи.

5.3 Дополнительные пункты

• Укажите, сохраняет ли подрядчик право демонстрировать проект в портфолио (обычно с согласием заказчика).
• Если используются open-source компоненты — укажите ссылки и лицензии; укажите, кто отвечает за соблюдение лицензий.
• Обсудите escrow исходников при долгосрочных проектах.

6. Гарантии, багфикс, поддержка и сопровождение

Определите гарантийный период и SLA. Гарантия покрывает ошибки, вызванные работой подрядчика, но не изменения требований заказчика.

6.1 Пример гарантийных условий

«Подрядчик предоставляет гарантийный период 60 календарных дней с момента подписания акта приёмки. За этот период подрядчик исправляет выявленные дефекты бесплатно. Дефект — поведение, при котором функциональность не соответствует Acceptance Criteria». Также опишите порядок обращения (трекинг багов, тикет‑система).

6.2 Служба поддержки и SLA

• Уровни поддержки: приоритеты (P1–P4), время реакции, время решения.
• Платная поддержка: месячный ретейнер или почасовая ставка.
• Условия резервного копирования, мониторинга и обновлений безопасности.

7. Изменения в объёме работ (change requests)

Всегда ожидайте изменений: оговорите процедуру и формулу оценки дополнительных работ.

7.1 Процесс изменений

1. Сторона, инициирующая изменение, направляет письменный запрос с описанием.
2. Подрядчик оценивает время и стоимость в течение N рабочих дней.
3. После согласования оформляется дополнительное соглашение/приложение к договору с новыми сроками и суммой.

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

8. Ответственность, штрафы и форс‑мажор

8.1 Ограничение ответственности

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

8.2 Штрафы и пени

Можно прописать пеню за просрочку сдачи: например, 0,1% от суммы за каждый день просрочки, но не более 5% общей стоимости. Альтернатива — стимулирующие бонусы за досрочную сдачу.

8.3 Форс‑мажор

Определите обычные обстоятельства непреодолимой силы и порядок уведомления. Форс‑мажор не освобождает полностью от обязательств — обычно даёт отсрочку.

9. Специфика SEO и аналитики в договоре

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

9.1 Что прописать для SEO

• Техническая оптимизация: корректная семантическая разметка, ЧПУ, meta-теги, canonical, sitemap.xml, robots.txt, скорость загрузки.
• Функционал для контент‑менеджера: удобная структура контента, шаблоны meta, возможность редиректов 301 без программиста.
• Настройка аналитики и целей: GA4, GTM, конверсии, UTM‑разметка.
• Передача отчётности и доступов: доступ к Search Console, GA, файлам sitemap и robots.

9.2 KPI и ожидания

Не ставьте KPI по позиции в первые 2–3 месяца без оговорки бюджета на контент и внешние факторы. Пишите реалистичные метрики: улучшение Core Web Vitals, сокращение времени отклика, рост органического трафика через 3–6 месяцев.

9.3 Интеграция с платной рекламой

Укажите, что платная реклама рассматривается как ускоритель запуска трафика, но не заменяет базовую SEO‑оптимизацию. Пропишите передачу UTM‑меток и правила отслеживания конверсий.

10. Модели ценообразования: фикс‑прайс vs Time & Materials

Выбор модели влияет на риски:

• Фикс‑прайс — заказчик получает предсказуемую цену, но подрядчик компенсирует риск неучтённых требований повышением стоимости или жёстким ТЗ.
• Time & Materials — гибкость и прозрачность по затратам, но нужен контроль часов и лимиты бюджета.

Гибридный подход — базовый фикс с опцией доработок по часам — часто работает лучше всего.

11. Практические формулировки и примеры клауз

11.1 Пример предмета договора

"Подрядчик обязуется разработать и передать Заказчику веб‑сайт (frontend + backend), включая дизайн, верстку, интеграции согласно Техническому заданию (Приложение №1), а Заказчик обязуется принять и оплатить выполненные работы в порядке, установленном настоящим договором."

11.2 Пример передачи исходников

"После полной оплаты Подрядчик предоставляет Заказчику доступ к репозиторию (Git) с полными исходными кодами и SQL‑дампом базы данных, а также архив с макетами Figma и инструкцией по деплою. Передача подтверждается актом приёмки исходных материалов."

11.3 Пример гарантии

"Подрядчик предоставляет гарантийный период 60 календарных дней с момента подписания акта приёмки. В течение гарантийного периода Подрядчик обязан устранить обнаруженные и документально подтверждённые ошибки в сроки, не превышающие 5 рабочих дней для критических ошибок и 15 рабочих дней для некритичных."

12. Контрольный чек‑лист перед подписью договора

• Чёткое ТЗ и список deliverables — есть ли Приложение №1?
• Схема оплаты и даты платежей — понятны ли обстоятельства возврата предоплаты?
• Критерии приёмки и сроки проверки — прописаны ли они?
• Права на код и дизайн — когда и в каком объёме переходят?
• Гарантийный период и SLA — покрывают ли они все критичные сценарии?
• Пункт об изменениях — как учитываются дополнительные задачи?
• Доступы и деплой — кто отвечает за перенос на продакшен?
• Юридические риски: конфиденциальность, персональные данные, ограничения ответственности.

13. FAQ

Вопрос: Нужно ли в договоре указывать стек технологий?

Да, желательно. Укажите минимум — CMS, языки, фреймворки и версии (например, PHP 8.x, Laravel 9, React 18). Это снижает риск неожиданной замены технологий и совместимости в будущем.

Вопрос: Можно ли не передавать исходники клиенту?

Можно, но это риск для заказчика. Часто лучше передать исходники после полной оплаты и прописать условия доступа (например, read/write в git). Альтернативы — escrow исходников или предоставление доступа на продакшн‑сервер.

Вопрос: Как прописать работу с контентом и SEO?

Опишите обязанности по передаче/наполнению контентом: кто готовит тексты, изображения, мета‑теги; кто отвечает за первичную SEO‑оптимизацию страниц; как передаются права на контент.

Вопрос: Что делать, если подрядчик задерживает сдачу?

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

Вопрос: Как учесть платную рекламу?

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

14. Дальше — как работать с подрядчиком

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

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