Как проверить договор на разработку сайта до подписания

Споры по сайту начинаются не из-за суммы, а из-за приемки, доплат и прав на код. Какие приложения должны быть у договора, как устроить оплату по этапам и приемку, кому достается код и домен и что вы получите, если проект остановится. В конце список из 11 пунктов перед подписью.

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

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

Я менеджер проектов, а не юрист. Ниже то, что я советую проверить со стороны заказчика, который будет жить с этим проектом. Формулировки пунктов пусть посмотрит ваш юрист.

Какой это договор и почему это важно

Разработку сайта обычно оформляют как договор подряда (глава 37 Гражданского кодекса). Подряд отвечает за результат: подрядчик должен сдать работу, а заказчик ее принять и оплатить. Иногда присылают договор возмездного оказания услуг, и для разработки это неудачный вариант: услуга считается оказанной самим процессом, и спорить о результате сложнее. Для поддержки сайта услуги подходят, для создания сайта лучше подряд.

Второй вопрос, который решается на первой странице, — какая цена. По ст. 709 ГК РФ смета бывает твердой и приблизительной, и если в договоре не сказано иное, цена считается твердой. Подрядчик не вправе требовать ее увеличения, даже если объем оказался больше. Если смета приблизительная и ее нужно существенно превысить, подрядчик обязан заранее предупредить, а заказчик может отказаться и оплатить только сделанное.

Отсюда простое правило. Если в договоре написано «стоимость ориентировочная» без порядка ее изменения, просите либо твердую цену за этап, либо ставку за час и потолок часов на этап.

Что должно лежать в приложениях

Сам договор у большинства подрядчиков типовой. Ваш проект описан в приложениях, и проверять нужно прежде всего их. Если приложений нет, а предмет договора звучит как «разработка сайта согласно требованиям Заказчика», у вас нет способа доказать, что сайт сделан не тот.

Если ТЗ еще не готово, это нормально: часто первый этап договора и есть проектирование. Тогда в договоре должно быть сказано, что ТЗ согласуется по итогам первого этапа и становится приложением, а цена следующих этапов фиксируется после согласования. Как собрать само задание, подробно описано в статье про ТЗ на разработку сайта.

Смета как приложение к договору: как сравнить предложения по строкам

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

Для интернет-магазина это особенно заметно. На проектах, которые приходили к нам после другого подрядчика, причина, по которой одна смета была вдвое дешевле другой, почти всегда одна и та же: в ней не было каталога и наполнения. Работа от этого никуда не исчезала. Она возвращалась в середине проекта счетом на доплату или неделями, которые менеджеры заказчика тратили на перенос товаров.

Какие строки должны быть в смете магазина

Сведите предложения в общую таблицу. Если у подрядчика строки нет, работа либо не посчитана, либо спрятана в другой строке и всплывет доплатой.

Крупные строки попросите расписать в часах. Часы показывают, понимает ли подрядчик объем: если обмен с 1С оценен в 4 ч., его никто не проектировал, и настоящая оценка появится, когда менять подрядчика будет поздно. Часть подрядчиков работает по фиксированной цене и часы не показывает принципиально. Тогда просите хотя бы состав каждой строки: фиксированная цена без состава в приложении к договору превращается в цену за неизвестно что. Почему обмен считается отдельным проектом внутри проекта, подробно разобрано в статье про интеграцию 1С с сайтом на Битрикс.

Вопросы на первой встрече, ответы на которые попадут в договор

Несколько вопросов стоит задать до сметы, потому что ответы на них потом должны оказаться в приложениях. Если подрядчик сам не спросил, какая у вас учетная система и в каком состоянии номенклатура, смета посчитана вслепую, и в договоре окажется цена, которую придется пересматривать.

• Какую платформу и редакцию предлагаете и почему. Ответ «так надежнее» не годится. Редакция и ее стоимость попадают в строку «Лицензии», а требования к ней — в ТЗ. Для магазина на 1С-Битрикс нужна редакция не ниже «Малого бизнеса», для нескольких складов — «Бизнес»; логика выбора — в статье о том, какую редакцию 1С-Битрикс выбрать.
• Как проверите заказ до запуска. Нормальный ответ — список сценариев: оформление, оплата тестовым платежом, чек, письмо покупателю, заказ в 1С, смена статуса на сайте. Этот список и есть заготовка чек-листа приемки для акта.
• Кто конкретно будет делать работу. Имена и роли: руководитель проекта, разработчик, человек, который отвечает за обмен. «У нас большая команда» ответом не считается. Состав команды в договор обычно не пишут, но по ответу видно, кто будет отвечать на вопросы по этапам.
• Сколько стоит час работы после запуска. Эта ставка пойдет в раздел об изменениях объема и в будущий договор на поддержку, поэтому ее лучше услышать до подписания.

Сильный подрядчик на первой встрече задает больше вопросов, чем вы. Тот, кто сразу называет цену, обычно потом называет и доплату.

Если магазин на 1С‑Битрикс: что проверить у партнера и в лицензии

Партнерский статус проверяется на сайте вендора через форму проверки партнера 1С-Битрикс. Статус показывает, что компания продает лицензии и проходила сертификацию. Качество конкретной команды он не гарантирует, но компания без статуса, которая в договоре называет себя партнером, — повод закончить разговор. Юрлицо подрядчика заодно проверьте по выписке на сервисе ФНС: дату регистрации, адрес, руководителя, и сверьте их с реквизитами в договоре. Компания, зарегистрированная 2 месяца назад, с портфолио за 10 лет — повод спросить, где эти 10 лет.

Лицензия в смете должна стоять отдельной строкой с суммой и владельцем. После покупки ключ проверяется в форме вендора: она показывает владельца лицензии, редакцию и срок активности.

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

Красные флаги в смете

• Цену назвали до вопросов про учет, ассортимент и доставку.
• «Лицензия входит в стоимость» без суммы и имени владельца.
• Магазин с обменом с 1С обещают за 2 недели. На наших проектах один обмен с реальной выгрузкой и его тестирование занимают больше.
• Одна строка «интеграция с 1С» без состава или обмен, оцененный в 4 ч.
• Строк «Наполнение» и «Тестирование» нет: по умолчанию наполнение делаете вы, а тестирование никто.
• Подрядчик отказывается показать и часы, и состав строк.

Если смета прошла проверку, попросите приложить ее к договору именно в таком виде, по строкам. Тогда любая доплата потом сравнивается с конкретной строкой, и разговор «это входило» заканчивается за 5 минут.

Этапы, сроки и оплата

Нормальная схема для сайта — оплата по этапам: проектирование, дизайн, разработка, запуск. Аванс на этап, остаток после подписания акта по этапу. Так ни одна сторона не уходит далеко в минус. Предоплата за весь проект сразу — плохая идея, даже со скидкой: если на дизайне выяснится, что вы с подрядчиком не сработались, деньги за верстку и программирование уже у него.

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

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

Как устроена приемка работ

Приемка — самый недооцененный раздел договора. По ст. 720 ГК РФ заказчик обязан осмотреть и принять работу в порядке, который предусмотрен договором, а недостатки сразу заявить подрядчику. Если работу приняли без проверки, ссылаться на явные недостатки потом нельзя.

На практике это значит, что акт, подписанный не глядя, закрывает спор. Поэтому в договоре ищите 4 вещи.

1. Где сдается работа. Сайт показывают на тестовом адресе с доступом в админку. Скриншоты и запись экрана приемкой не считаются.
2. Сколько дней на проверку. 5–10 рабочих дней на этап — разумно. 2 дня на проверку каталога с обменом с 1С — нет.
3. Что происходит при молчании. Почти во всех договорах есть пункт «если заказчик не направил мотивированный отказ в срок, работа считается принятой». Он нормален, просто внесите срок в календарь.
4. Что считается замечанием. Отступление от ТЗ и ошибка — повод не подписывать акт. Новое пожелание («а давайте кнопку зеленой») — уже изменение объема, о нем следующий раздел.

Если в акте вы перечислили недостатки и срок их исправления, на них можно ссылаться и после подписания (п. 2 ст. 720). Это удобный компромисс, когда сайт в целом готов и задерживать оплату этапа из-за 5 мелочей не хочется.

Скрытые недостатки, которые при обычной проверке не увидеть, по той же статье можно заявить и после приемки, в разумный срок после обнаружения. Но лучше не доводить: в чек-лист приемки стоит включить сценарии, на которых сайт зарабатывает. Отправка заявки до CRM, оформление заказа до оплаты, обмен с 1С на реальной выгрузке.

Изменения объема и доплаты

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

Хороший договор описывает порядок:

• заказчик присылает запрос на изменение письмом или в системе задач;
• подрядчик в оговоренный срок оценивает его в часах и сообщает, как сдвинется срок;
• работа начинается только после согласования оценки в письменной форме;
• ставка за час на такие работы записана в договоре заранее.

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

Кому принадлежат код, дизайн и макеты

Тут многие успокаиваются фразой «сайт же сделан для нас». По ст. 1296 ГК РФ исключительное право на программу или произведение, созданное по заказу, принадлежит заказчику, если договором не предусмотрено иное. Ключевые слова — «если не предусмотрено иное». Договор может оставить права у подрядчика, и тогда у вас будет только право пользоваться сайтом для целей договора. Изменить его у другого подрядчика или использовать дизайн в новом проекте формально будет нельзя.

Что проверить в этом разделе:

• Права на созданное. Исключительное право на код, написанный под ваш проект, и на дизайн переходит к заказчику, лучше с момента оплаты этапа.
• Сторонние компоненты. CMS, готовое решение, модули, шрифты, фотостоки остаются у правообладателей. Вам передается лицензия, и она должна быть оформлена на вашу компанию. Права на сам 1С-Битрикс вы не получите никогда, и это нормально.
• Наработки подрядчика. Свои библиотеки, которые подрядчик использует во всех проектах, он вправе оставить себе. Тогда в договоре должно быть сказано, что вы можете пользоваться ими бессрочно и без доплат.
• Что передается физически. Исходный код в репозитории, макеты в исходном формате, документация по установке и интеграциям.

Права без файлов мало что дают. Мы в Design Lab отдаем заказчику доступы, исходный код и макеты и ведем паспорт проекта с документацией, и именно этот перечень я советую требовать от любого подрядчика.

Домен, хостинг и доступы

Самая частая история, которая всплывает через 2–3 года: домен зарегистрирован на менеджера подрядчика или на него самого. Пока отношения хорошие, разницы нет. Когда вы решите сменить подрядчика, окажется, что вернуть домен можно только по его доброй воле.

Поэтому в договоре или в отдельном письме до старта зафиксируйте: домен регистрируется на заказчика (юрлицо или ИП), хостинг и почта оформлены на заказчика и оплачиваются с его счета, лицензии CMS и модулей выписаны на заказчика. Подрядчику достаточно рабочих доступов. Доступы к админке, хостингу, Метрике и репозиторию передаются вам в день запуска.

Отдельно проверьте, кто будет администратором Яндекс Метрики и Вебмастера. Если счетчик создан в аккаунте подрядчика, история посещаемости уйдет вместе с ним.

Гарантия и ошибки после запуска

Слово «гарантия» в договорах на сайт означает разные вещи, и их стоит развести.

Первое: бесплатные правки после запуска. Обычно это месяц, когда подрядчик доделывает мелочи, найденные на живом сайте. Второе: исправление ошибок, то есть ситуаций, когда сайт работает не так, как описано в ТЗ. Третье: все остальное: новые функции, обновления платформы, проблемы из-за того, что сайт после запуска правил кто-то другой. Это уже поддержка, и она оплачивается отдельно.

Если гарантийный срок в договоре не установлен, по ст. 724 ГК РФ требования по качеству можно предъявить, если недостатки обнаружены в разумный срок, но в пределах 2 лет со дня передачи результата. Если гарантийный срок установлен, требования предъявляют по недостаткам, обнаруженным в течение него. Короткий гарантийный срок в договоре меняет общее правило, и как это работает в вашем случае, лучше спросить юриста.

Со стороны проекта мне важнее другое: чтобы в договоре было написано, что считается ошибкой (несоответствие ТЗ), за какой срок ее исправляют и что гарантия не распространяется на изменения, сделанные не подрядчиком. Последнее подрядчик впишет сам, и это справедливо.

Если проект придется остановить

Об этом не хочется думать на старте, но раздел о расторжении стоит прочитать дважды. По ст. 717 ГК РФ, если договор не предусматривает иное, заказчик может отказаться от договора в любой момент до сдачи результата, оплатив часть цены пропорционально выполненной работе и возместив подрядчику убытки в пределах оставшейся цены.

Деньги здесь не главное. Главное — что вы получаете на руки при остановке. Проверьте, что договор обязывает подрядчика передать все, что сделано к этому моменту: макеты, код текущего состояния, доступы. Без этого пункта оплаченный наполовину проект придется начинать с нуля у нового исполнителя.

Короткий список перед подписью

1. Предмет договора ссылается на ТЗ или прямо говорит, что ТЗ согласуется на первом этапе.
2. У каждого этапа есть результат, срок и сумма.
3. Оплата следующего этапа идет после акта по предыдущему.
4. Срок сдвигается на время задержек со стороны заказчика, и это записано.
5. Работа сдается на тестовом адресе, на проверку есть 5–10 рабочих дней.
6. Изменения оформляются письменно, ставка за час указана.
7. Исключительное право на код и дизайн переходит к заказчику.
8. Домен, хостинг и лицензии оформлены на заказчика.
9. Перечислено, что передается: код, макеты, доступы, документация.
10. Понятно, что считается ошибкой и сколько длится гарантия.
11. При расторжении подрядчик передает все сделанное.

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