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

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

Предмет договора и состав работ

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

• Что именно делается: тип сайта, количество страниц или экранов, наличие мобильной версии.
• Что входит в работу: структура, тексты, дизайн, вёрстка, программирование, наполнение, аналитика, перенос на хостинг.
• Что не входит — этот список полезнее первого. Например: фотосъёмка, покупка домена и хостинга, рекламные кампании, ведение сайта после запуска.
• Ссылка на ТЗ как на приложение. Договор без приложенного технического задания описывает намерение, а не работу.
• Кто отвечает за материалы заказчика: логотип, фотографии, тексты, права на них.

Сроки и что считается сдачей

Срок «30 дней» ничего не значит, пока непонятно, с какого дня он идёт, когда останавливается и чем заканчивается. Это три отдельных вопроса, и в хорошем договоре на каждый есть ответ.

• От какого события считается срок: от подписания, от поступления предоплаты, от передачи материалов заказчиком.
• Останавливается ли срок, пока заказчик согласовывает макет или не прислал тексты. Обычно да — и это справедливо, но должно быть написано, а не подразумеваться.
• Что считается сдачей: например, сайт открывается на боевом домене, формы отправляют заявки, аналитика собирает данные.
• Сколько дней у заказчика на приёмку и что происходит, если он молчит. Часто предусматривают, что работа считается принятой через несколько дней после передачи, — распространённая практика, но вы должны о ней знать заранее.
• Как оформляется сдача: акт, письмо на почту, сообщение. Важно, чтобы способ был один и обе стороны им пользовались.

Порядок оплаты

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

Отдельно посмотрите, что происходит при досрочном расторжении: оплачивается ли фактически выполненная часть и передаётся ли заказчику то, что уже сделано. Ещё уточните, кто платит комиссии и как оформляются закрывающие документы, если вы юрлицо или ИП: бухгалтерии нужен не только факт оплаты, но и бумага под него.

Передача прав на результат — пункт, который пропускают чаще всего

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

• Что передаётся: дизайн-макеты, исходный код, тексты и графика, созданные для проекта.
• Когда передаётся — самое важное. Частая формулировка: права переходят после полной оплаты по договору. Если момент не назван, вы можете годами пользоваться сайтом, не имея определённости по правам на него.
• В каком объёме: можете ли вы дорабатывать сайт сами, передавать его другому подрядчику, использовать макеты в рекламе и на других носителях.
• Что остаётся у подрядчика: часто это его собственные библиотеки, шаблоны и наработки, а также право показывать работу в портфолио. Это нормально, но должно быть написано, а не выясняться потом.
• Как быть с чужими материалами: шрифты, фотостоки, платные плагины и темы. Уточните, на кого оформлена лицензия и не придётся ли вам её продлевать.

Доступы и исходники

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

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

Правки после сдачи и поддержка

Здесь ожидания расходятся сильнее всего. Для подрядчика правка — это новая работа, для заказчика — «мелочь, поменяйте телефон в шапке». Помогает разделить три разные вещи и описать каждую отдельно.

• Ошибки: сайт работает не так, как описано в ТЗ. Их исправляют бесплатно, обычно в течение оговорённого срока после сдачи. Проверьте, что этот срок в договоре есть.
• Правки по ходу проекта: сколько кругов правок макета входит в цену и что считается новым кругом. Без этого пункта согласование дизайна не имеет дна.
• Доработки после запуска: новые блоки, страницы, функции. Оплачиваются отдельно — по часам или пакетом; полезно заранее знать ставку.

Ответственность за срыв сроков

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

• Предусмотрены ли последствия просрочки и для кого именно.
• Ограничена ли сумма ответственности: часто её ограничивают стоимостью работ по договору.
• Что считается основанием для переноса срока — как правило, задержка материалов и согласований со стороны заказчика.
• Как расторгается договор, если работа встала: порядок уведомления и расчёт за уже выполненное.

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

Короткий список перед подписанием

Мы работаем как ИП, по договору и с закрывающими документами, а права на макет и код переходят заказчику после оплаты по договору. Это не редкость на рынке и не повод для гордости — это тот минимум, который стоит требовать от любого подрядчика, включая нас.