Договор на разработку сайта обычно читают один раз и по диагонали, а спорят потом по трём вопросам: что считается готовым результатом, кому принадлежат права и как именно принимается работа. Разбираем 12 пунктов, которые стоит проверить до подписания.
Мы работаем с 2008 года и подписали не одну сотню договоров - и как исполнитель, и как субподрядчик у других студий. Почти все конфликты, которые доходили до претензий, начинались не с денег. Начинались они с фразы "мы думали, это входит в стоимость".
Договор эту фразу либо предотвращает, либо нет. Ниже пункты, которые её предотвращают, и то, как они выглядят в нормальном тексте.
Где договоры ломаются чаще всего
Три типовых сценария из практики.
Расползание объёма. В договоре написано "разработка корпоративного сайта". Заказчик считает, что многоязычность и личный кабинет входят, исполнитель считает, что нет. Формально правы оба, потому что состав работ нигде не зафиксирован.
Вечная приёмка. Сайт сделан, но акт не подписан: то отпуск, то новые замечания раз в две недели. Проект висит месяцами, деньги не закрыты, команда занята тем же проектом вместо следующего.
Права и исходники. Через год бизнес хочет сменить подрядчика и выясняет, что домен зарегистрирован на студию, хостинг оформлен на её аккаунт, а исходные макеты никто не отдаёт.
Каждый сценарий закрывается одним-двумя абзацами в тексте договора.
Пункты 1-3: что делаем, когда и за сколько
1. Предмет и состав работ. Формулировка "разработка сайта" сама по себе не значит ничего. Рабочий вариант: предмет описан общими словами, а состав работ вынесен в техническое задание, которое подписывается как приложение. В самом договоре нужна строчка о том, что ТЗ - его неотъемлемая часть, иначе приложение легко объявить необязательным черновиком. Как выглядит нормальное ТЗ, разбирали в статье про шаблон технического задания.
2. Этапы и сроки. Сроки считать в рабочих днях и от события, а не от календарной даты. "20 рабочих дней с момента передачи контента" честнее, чем "до 15 октября": контент почти всегда задерживается, и жёсткая дата превращается в просрочку исполнителя по вине заказчика. Хорошо, когда у каждого этапа есть свой результат: прототип, макеты, вёрстка, наполнение, запуск.
3. Порядок оплаты. Обычная схема на рынке - аванс 30-50%, остальное по этапам или по факту приёмки. Проверьте, привязан ли платёж к подписанию акта этапа. Если не привязан, платежи живут отдельной жизнью и обсуждать придётся каждый.
Пункты 4-5: приёмка и правки
4. Приёмка и срок на замечания. Самый полезный пункт во всём договоре. Он должен отвечать на два вопроса: сколько у заказчика дней на проверку и что происходит, если он молчит. Типовая формулировка: 5 рабочих дней на мотивированные замечания в письменном виде, после чего работа считается принятой. Это дисциплинирует обе стороны. Что именно смотреть при приёмке - отдельный длинный список, он в статье как принять сайт у студии.
5. Число итераций правок. Правки должны быть конечными. Нормальная запись: две итерации на каждый этап дизайна в рамках утверждённого ТЗ, дальше по отдельной смете с почасовой ставкой. Без предела правок студия закладывает этот риск в цену заранее, и вы платите за него независимо от того, понадобились правки или нет.
Пункты 6-7: права, исходники и доступы
6. Передача прав на результат. Здесь больше всего мифов. Общее правило закона про созданное по заказу почти всегда идёт с оговоркой "если договором не предусмотрено иное", и подрядчики этой оговоркой пользуются. Поэтому пункт должен быть явным: исключительное право на дизайн, тексты, фотографии и написанный под проект код переходит заказчику, момент перехода - подписание финального акта или полная оплата. Подробный разбор с оговорками - в статье кому принадлежат права на сайт.
Отдельно про чужие компоненты. Шрифты, стоковые фотографии, платные плагины и лицензия CMS остаются на своих условиях, права на них передать невозможно. В договоре стоит перечислить, что куплено и на чьё имя оформлено.
7. Исходники и доступы. Пункт, который выручает через год. Что должно быть перечислено:
- домен зарегистрирован на заказчика, административный контакт - его почта;
- хостинг оформлен на заказчика, даже если технически им управляет студия;
- исходные файлы дизайна передаются в редактируемом формате;
- доступы к CMS, панели хостинга, счётчикам аналитики и репозиторию передаются при завершении работ;
- почтовые ящики и подключённые платные сервисы оформлены на заказчика.
Если хоть один пункт остаётся на стороне подрядчика, любая смена команды превращается в переговоры.
Пункты 8-9: контент заказчика и гарантия
8. Ответственность за контент. Тексты, фотографии и логотипы передаёт заказчик, и за их юридическую чистоту отвечает он же. Стандартная формулировка снимает с исполнителя ответственность по претензиям правообладателей за материалы, полученные от заказчика. Это не формальность: иски за чужую фотографию на сайте - живая практика, суммы обычно измеряются десятками тысяч рублей.
9. Гарантийный период. Гарантия на сайт бывает 3, 6 и 12 месяцев, но срок менее важен, чем её содержание. В гарантию входит исправление ошибок, то есть отклонений от ТЗ и сломанной функциональности. Не входит: новые доработки, изменения дизайна, обновление CMS и плагинов, восстановление после правок посторонними. Если написано просто "гарантия 12 месяцев", попросите дописать границу, иначе каждый баг будет предметом торга.
Пункты 10-12: изменения, расторжение, конфиденциальность
10. Порядок изменения ТЗ. Задачи меняются в любом проекте, вопрос в процедуре. Рабочий механизм: изменение оформляется дополнительным соглашением со своей ценой и своим сдвигом срока. Без этого пункта каждое "давайте ещё добавим" либо делается за счёт исполнителя, либо становится поводом для ссоры.
11. Расторжение и судьба оплаченного. Договор должен отвечать, что происходит, если стороны расходятся на середине. Обычная схема: заказчик оплачивает фактически выполненный и принятый объём, исполнитель передаёт всё сделанное на этот момент, аванс за невыполненные этапы возвращается. Отдельно проверьте, что при расторжении вам передают наработки, а не только возвращают деньги: макеты и вёрстка без прав на них бесполезны.
12. Конфиденциальность. Для B2B, медицины и юридических практик пункт обязательный. Подрядчик получает доступ к базе клиентов, ценам, иногда к персональным данным. Опишите, что считается конфиденциальным, на какой срок и что происходит с данными после окончания работ. Если на сайте обрабатываются персональные данные и подрядчик их видит, отношения оформляются отдельно поручением на обработку: ответственность перед посетителями всё равно останется на вас как на владельце сайта.
Подряд или услуги: что это меняет
Сайт - результат, который можно потрогать: файлы, макеты, работающая система. Поэтому разработку обычно оформляют по модели подряда, где есть результат, акт на него и гарантия. Модель возмездного оказания услуг ближе к поддержке, SEO и консультациям, где оплачивается процесс, а не итог.
Смешанный вариант встречается чаще всего и это нормально: разработка по правилам подряда плюс сопровождение как услуга. Ненормально, когда разработку целиком оформляют как чистые услуги. Тогда у вас нет результата, который можно не принять, и предъявлять претензии формально не к чему.
Красные флаги в чужом договоре
| Что видите в тексте | Чем это грозит |
|---|---|
| ТЗ нет или оно "будет согласовано позже" | Состав работ определяет исполнитель |
| Про права не сказано ничего | Спор об умолчаниях вместо готового ответа |
| Правки без ограничения количества | Риск заложен в цену, сроки плавают |
| Домен и хостинг оформляются на исполнителя | Смена подрядчика через переговоры |
| Сроки календарными датами без привязки к контенту | Формальные просрочки с обеих сторон |
| Приёмка без срока на замечания | Проект не закрывается месяцами |
| Гарантия без описания, что в неё входит | Каждая ошибка - предмет торга |
Ни один флаг не означает, что подрядчик жулик. Чаще это шаблон из интернета, который никто не перечитывал. Спокойная просьба дописать пункт заодно показывает, как будет строиться работа дальше: вменяемый исполнитель правит текст за день, а тот, кто отвечает "у нас так со всеми", ведёт себя так же и в проекте. Что ещё смотреть на этапе выбора - в статье про выбор веб-студии.
Как это устроено у нас
Договор занимает шесть страниц, ТЗ идёт приложением номер один, смета - приложением номер два. Домен и хостинг с первого дня оформляем на заказчика, даже когда платим за них сами и потом перевыставляем в счёте. Права передаём финальным актом, срок на замечания при приёмке - 5 рабочих дней, две итерации правок на этап дизайна, гарантия 6 месяцев на ошибки в рамках ТЗ.
Для мелких работ по поддержке договор не подписываем: там работает договор-оферта на сайте, оплата счёта означает согласие с его условиями. Возить бумаги ради задачи на два часа никому не нужно.
Что сделать перед подписанием
- Прочитать договор целиком вместе с приложениями и выписать всё непонятное одним списком.
- Проверить, что ТЗ приложено и подписывается, а не обещано на потом.
- Найти в тексте слова о передаче исключительных прав. Если их нет, попросить добавить.
- Убедиться, что домен и хостинг оформляются на вас.
- Проверить срок на замечания при приёмке и число итераций правок.
- Спросить письменно, что входит в гарантию и что в неё не входит.
- Уточнить процедуру изменения ТЗ и порядок расчётов при расторжении.
- Сверить реквизиты, а у юрлица ещё и полномочия того, кто подписывает.
Восемь пунктов занимают примерно час. Разбирательство по проекту на 400 000 рублей занимает от полугода, и выигрывает в нём тот, у кого бумаги в порядке.
Что смотреть перед подписанием
Хороший договор на разработку сайта не про запугивание сторон санкциями, а про то, чтобы у каждого спорного вопроса был заранее известный ответ. Три места, где обычно и возникают споры: состав работ, приёмка и права на результат. Если эти три закрыты, остальное решается перепиской. Отсутствие пункта почти всегда играет против заказчика, потому что текст писал не он.
Состав работ проще зафиксировать до договора, а не после. Опишите задачу по пунктам в брифе: из ответов на него и вырастает приложение с ТЗ, на которое потом ссылается приёмка.
