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

Когда заказчик и разработчик ссорятся, кажется, что дело в качестве работы. Но если разобраться, чаще всего причина в другом. Каждая сторона по-своему поняла, о чём договорились. Заказчик думал, что правки входят в цену. Разработчик думал, что нет. Заказчик ждал сайт с личным кабинетом. Разработчик делал сайт без него. И в договоре нет ни слова, кто прав. Я не юрист и не заменяю юриста. Но я много раз видел, какие пункты спасают проект, а без каких он превращается в спор. Ниже — этот список.

Предмет и этапы: что делается и когда

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

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

Приёмка: как понять, что работа сдана

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

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

Доработка или новая задача: главный источник споров

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

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

Права на результат и доступы

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

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

Какие пункты нужны и что будет без них

Вот сводка по основным пунктам договора.

Гарантия, поддержка, сроки заказчика и расторжение

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

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

И последнее — расторжение. Бывает, что проект приходится остановить. Договор должен отвечать, что оплачивается за уже сделанное и как передаются результаты. Тогда расставание проходит спокойно.

Как это выглядит, когда настроено

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

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

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

Частые вопросы

Можно ли работать без договора, если сумма небольшая?

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

Кто должен писать техническое задание?

Лучше вместе. Заказчик знает задачу, разработчик знает, как её описать, чтобы потом не было разночтений.

Что если задание меняется по ходу работы?

Это нормально. Изменения оформляются как новая задача или как дополнение к договору, с новым сроком и ценой.

Нужен ли юрист, если договор простой?

Я советую показать договор юристу. Он увидит то, что не видно со стороны заказчика или разработчика.

Почему права переходят только после оплаты?

Так обе стороны защищены. Разработчик уверен в оплате, заказчик получает права в понятный момент.

Коротко о главном

Споры с подрядчиком редко начинаются с кода. Чаще они начинаются с договора, где не записано, что именно делается и как это принимают.

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

Я работаю по договору с этапами и описанием результата, а домен и хостинг всегда оформляются на заказчика. Если хотите обсудить свою задачу или разобрать договор, который вам уже прислали, с точки зрения разработки, я помогу. Напишите в Telegram, MAX или VK.