Договор на разработку сайта: что в нём должно быть

Зачем договор на маленький проект?

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

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

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

Формат может быть простым: две-три страницы с подписями, отсканированные и отправленные по почте. Раздел «форс-мажор» на полторы страницы в таком договоре никому не помогает.

Как описать предмет договора?

Списком. Формулировка «разработка сайта под ключ» ничего не определяет: сколько это страниц, с текстами или без, с админкой или без, с переносом на хостинг или нет?

Примерный список:

• Количество страниц или экранов с их названиями: главная, услуги, о компании, контакты.
• Что делает разработчик с контентом: верстает ваши тексты или пишет их сам.
• Откуда берутся изображения: ваши фото, платный фотобанк, бесплатные стоки.
• Какие формы есть и куда уходят заявки: почта, Telegram, CRM.
• Какие подключаются сервисы: аналитика, карта, мессенджеры, оплата.
• Есть ли админка и что именно в ней можно менять.
• Адаптив: под какие устройства и какие браузеры.

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

Фикс-цена или почасовая оплата?

Фикс-цена подходит, когда задача понятна и границы описаны: лендинг, корпоративный сайт, типовой магазин. Вам она удобна тем, что сумма известна заранее и за таймером следить не нужно. Проекты до 60–70 тысяч рублей я почти всегда делаю по фиксу, потому что их можно оценить достаточно точно.

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

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

Я использую компромисс: фикс на основную работу и почасовая ставка на всё, что появляется по ходу, с потолком «не более стольких-то часов без отдельного согласования». Так вы защищены от счёта, которого не ждали.

Сроки и что считается срывом

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

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

Разбейте проект на этапы с датами: прототип, дизайн, вёрстка, интеграции, запуск. Тогда отставание заметно уже на второй неделе, задолго до дедлайна. Укажите и то, сколько времени у вас есть на согласование каждого этапа; два-три рабочих дня разумно. Иначе разработчик неделю ждёт ответа, а срок сгорает.

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

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

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

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

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

Дизайн. Макеты передаются вам, желательно в исходном формате, а не картинками. Если в проекте платные шрифты или фото из платного стока, в договоре указывают, на кого оформлена лицензия и кто её продлевает.

Домен. Регистрируется на ваши данные и ваш аккаунт у регистратора. Разработчику можно дать доступ, но владелец вы.

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

Аккаунты сервисов. Аналитика, почта на домене, платёжный шлюз, CRM создаются под вашей учётной записью, а разработчик получает доступ как сотрудник. В договоре хватит одной строки: все учётные записи регистрируются на заказчика, доступы передаются в день сдачи. Как проверить это на уже работающем сайте, я описал в статье о том, как не потерять сайт.

Сколько правок входит в цену?

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

Круг означает, что вы собираете все замечания разом и присылаете одним списком, а не по одному сообщению в течение недели. Правки в границах согласованного предмета входят в цену.

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

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

Какую предоплату вносить и как её возвращать?

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

Важнее размера то, что происходит с предоплатой при отказе. Формулировка, которая устраивает обе стороны: если вы отказываетесь от проекта, вам возвращают предоплату за вычетом фактически выполненной работы, а выполненное передают вам. Варианты «предоплата не возвращается» и «возвращается полностью» несправедливы к одной из сторон.

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

Если подрядчик пропал

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

Ущерб заранее снижают четыре вещи:

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

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

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

Чек-лист перед подписанием

Перед подписанием проверьте, что документ отвечает на семь вопросов:

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

Если подрядчик спокойно отвечает на все семь и не против это записать, договор можно уложить хоть в одну страницу. Если он уходит от ответа, особенно про доступы и код, вы уже узнали о нём главное. Что ещё спросить до оплаты, есть в статье о выборе разработчика.