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

Почему договор важнее портфолио

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

Этапы и сроки: календарь вместо «по мере готовности»

Первое, что нужно проверить, — разбит ли проект на этапы с конкретными результатами. Формулировка «разработка сайта — 60 рабочих дней» плохая не потому, что срок большой, а потому, что два месяца вы не будете видеть ничего. Рабочая схема: прототип — свой срок, дизайн главной страницы — свой, дизайн внутренних, вёрстка, наполнение, запуск — по каждому этапу понятно, что вы получите и когда.

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

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

Порядок приёмки: пункт, из-за которого проекты зависают

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

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

Итерации правок: сколько раз можно сказать «не то»

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

Права на сайт после разработки: код, дизайн, контент

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

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

Права на сайт после разработки: код, дизайн, контент

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

Да

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

Да

Красный флаг: сайт работает только на закрытой платформе исполнителя — какие бы права ни были на бумаге, забрать такой сайт де-факто невозможно.

Да

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

Да

Обычная встречная просьба: право исполнителя показывать работу в портфолио — соглашаться или нет, решать вам.

Да

Текст схемы и все данные

Права на сайт после разработки: код, дизайн, контент

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

Да

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

Да

Красный флаг: сайт работает только на закрытой платформе исполнителя — какие бы права ни были на бумаге, забрать такой сайт де-факто невозможно.

Да

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

Да

Обычная встречная просьба: право исполнителя показывать работу в портфолио — соглашаться или нет, решать вам.

Да

Практический тест на переносимость: спросите, в каком виде вам передадут исходники и сможет ли другой разработчик продолжить работу. Мы в АОСА собираем сайты на статической архитектуре — результат работы это набор файлов и исходный код в репозитории, который переносится на любой хостинг; почему так надёжнее, мы объясняли в статье о статических сайтах для бизнеса.

Передача доступов: сайт не ваш, пока доступы не у вас

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

• Домен зарегистрирован на вас — на компанию или ИП, а не на подрядчика. Это критично: домен на чужом имени означает, что адрес сайта вам не принадлежит.
• Хостинг-аккаунт ваш; исполнитель работает через делегированный доступ, который вы можете отозвать.
• Исходный код: репозиторий или архив с исходниками, а не «файлы лежат на сервере».
• Админка, аналитика, панели вебмастеров — созданы на ваших аккаунтах, подрядчик добавлен как гость.
• Пароли передаются по описанной в договоре процедуре, а не «вышлем как-нибудь после запуска».

Передача доступов: сайт не ваш, пока доступы не у вас

Домен зарегистрирован на вас — на компанию или ИП, а не на подрядчика. Это критично: домен на чужом имени означает, что адрес сайта вам не принадлежит.

Да

Хостинг-аккаунт ваш; исполнитель работает через делегированный доступ, который вы можете отозвать.

Да

Исходный код: репозиторий или архив с исходниками, а не «файлы лежат на сервере».

Да

Админка, аналитика, панели вебмастеров — созданы на ваших аккаунтах, подрядчик добавлен как гость.

Да

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

Да

Текст схемы и все данные

Передача доступов: сайт не ваш, пока доступы не у вас

Домен зарегистрирован на вас — на компанию или ИП, а не на подрядчика. Это критично: домен на чужом имени означает, что адрес сайта вам не принадлежит.

Да

Хостинг-аккаунт ваш; исполнитель работает через делегированный доступ, который вы можете отозвать.

Да

Исходный код: репозиторий или архив с исходниками, а не «файлы лежат на сервере».

Да

Админка, аналитика, панели вебмастеров — созданы на ваших аккаунтах, подрядчик добавлен как гость.

Да

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

Да

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

Гарантия на сайт — это обязанность исполнителя бесплатно исправлять ошибки и несоответствия ТЗ, обнаруженные после запуска; типичный срок — от трёх месяцев до года. Важно отличать гарантию от поддержки: гарантия закрывает дефекты, а развитие сайта — новые страницы, функции, доработки — это отдельная услуга, в АОСА она стоит от 15 000 ₽ в месяц. Красный флаг в гарантийном блоке — условие, при котором гарантия аннулируется от любого вмешательства: «если заказчик изменил хотя бы один файл». Честная формулировка мягче: гарантия не распространяется на части сайта, изменённые третьими лицами.

Этапы оплаты разработки сайта: честная схема

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

Оплата по этапам: как выглядит сбалансированная схема

Этап: Аванс при подписании

Что вы получаете и проверяете: Старт работ: бриф, структура, прототип

Типичная доля: 30–50%

Этап: После утверждения дизайна

Что вы получаете и проверяете: Макеты ключевых страниц

Типичная доля: 20–30%

Этап: После вёрстки и наполнения

Что вы получаете и проверяете: Рабочий сайт на тестовом домене

Типичная доля: 20–30%

Этап: Запуск и передача

Что вы получаете и проверяете: Сайт на боевом домене, доступы, исходники, акт

Типичная доля: 10–20%

Текст схемы и все данные

Оплата по этапам: как выглядит сбалансированная схема

Этап: Аванс при подписании

Что вы получаете и проверяете: Старт работ: бриф, структура, прототип

Типичная доля: 30–50%

Этап: После утверждения дизайна

Что вы получаете и проверяете: Макеты ключевых страниц

Типичная доля: 20–30%

Этап: После вёрстки и наполнения

Что вы получаете и проверяете: Рабочий сайт на тестовом домене

Типичная доля: 20–30%

Этап: Запуск и передача

Что вы получаете и проверяете: Сайт на боевом домене, доступы, исходники, акт

Типичная доля: 10–20%