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

Вы нашли исполнителя, ударили по рукам, перевели предоплату — а через два месяца получаете сайт, который работает не так, как вы представляли, сроки съехали, а вернуть аванс или забрать наработки не выходит. В девяти случаях из десяти корень проблемы один: договор на разработку сайта был или на одну страницу «сделать сайт, оплата 50/50», или его не было вовсе. Хороший договор — это не бюрократия и не признак недоверия, а инструмент, который защищает обе стороны и превращает устные обещания в проверяемые обязательства. Ниже — что в нём обязательно должно быть, чтобы вы не остались ни с деньгами, ни с проектом, и короткий чек-лист перед подписанием.

Зачем вообще нужен договор, а не переписка в мессенджере

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

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

Техническое задание — приложение к договору, а не пожелания на словах

Самый важный пункт, который чаще всего пропускают. В самом договоре объём работ описывают общими словами, а конкретику выносят в техническое задание (ТЗ) — отдельное приложение, на которое договор ссылается. Именно ТЗ определяет, что считать выполненной работой, а что — дополнительной.

Хорошее ТЗ содержит: список страниц и экранов, функциональность (формы, личный кабинет, оплата, фильтры), интеграции (CRM, эквайринг, 1С), требования к адаптивности под мобильные, перечень того, кто предоставляет тексты и картинки. Отдельно проговаривают, что НЕ входит в проект — это спасает от бесконечных «а ещё добавьте вот это».

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

Этапы и порядок оплаты: никогда не платите 100% вперёд

Разбейте проект на этапы и привяжите оплату к сдаче каждого из них, а не к календарю. Типичная схема: аванс на старт (обычно 30–50%, зависит от объёма и доверия), затем оплата по завершении ключевых блоков — дизайн, вёрстка и функционал, финальный платёж после приёмки и запуска.

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

Отдельно зафиксируйте, что входит в стоимость этапа, а что оплачивается отдельно. Например, две-три итерации правок дизайна — в цене, а четвёртая переделка «всё заново» — по отдельной ставке. Это честно к обеим сторонам и убирает почву для скандалов.

Сроки и штрафы за срыв — с обеих сторон

Срок без ответственности — это пожелание, а не обязательство. В договоре нужны конкретные даты (или сроки в рабочих днях от старта этапа) и последствия их нарушения. Обычно это неустойка — небольшой процент от стоимости этапа за каждый день просрочки, с разумным потолком.

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

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

Передача исходников и прав — иначе сайт вам не принадлежит

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

Пропишите прямо: после полной оплаты исключительные права на сайт (код, дизайн, тексты) переходят к вам, вам передаются исходники, доступы к хостингу, домену, репозиторию и всем сервисам. Отдельно оговорите используемые сторонние компоненты и open-source — на них права не «передаются», но исполнитель гарантирует, что лицензии позволяют коммерческое использование.

Домен и хостинг регистрируйте на себя, а не на студию — это ваш актив. Если исполнитель предлагает «мы всё оформим на нас, так удобнее», это красный флаг: при конфликте вы рискуете потерять доступ к собственному сайту. В проектах, которые мы делаем — от обучающего Telegram-бота до производственного сайта с каталогом — заказчик всегда получает полный контроль над результатом и доступами, потому что это его бизнес-инструмент, а не наш.

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

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

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

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

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

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

FAQ

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

Формально да, но рискуете вы. Даже для лендинга минимальный договор с ТЗ, сроком и порядком оплаты стоит потратить полчаса — он защищает и вас, и исполнителя. Чем меньше проект, тем короче договор, но пункт про передачу прав и доступов нужен даже для одной страницы.

Кто должен готовить договор и ТЗ — я или студия?

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

Что делать, если исполнитель срывает сроки уже в процессе?

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

Насколько детальным должно быть ТЗ?

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

Сколько обычно занимает и стоит подготовка договора и ТЗ?

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

---

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