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

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

1. Предмет договора и техническое задание: фундамент проекта

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

**Что должно быть в ТЗ (или описании работ в договоре):**

  • **Цели и задачи проекта:** Для чего нужен сайт/приложение? Какие бизнес-проблемы он решает?
  • **Функциональные требования:** Что именно должен делать сайт/приложение? (Пример: "Пользователь должен иметь возможность зарегистрироваться", "На сайте должен быть каталог товаров с фильтрами", "Приложение должно отправлять push-уведомления"). Чем конкретнее, тем лучше.
  • **Нефункциональные требования:** Требования к производительности, безопасности, масштабируемости, дизайну (например, "время загрузки страницы не более 3 секунд", "поддержка 1000 одновременных пользователей").
  • **Дизайн-макеты (если применимо):** Утвержденные прототипы и дизайн-макеты, которые станут основой для верстки и разработки.
  • **Стек технологий:** Какие технологии будут использоваться (например, Python/Django, React, Swift/Kotlin). Это важно, если вы планируете дальнейшую поддержку или развитие проекта силами другой команды.
  • **Интеграции:** С какими внешними сервисами будет взаимодействовать ваш проект (CRM, платежные системы, сторонние API).

**Подводные камни:**

  • **Размытое ТЗ:** "Сделать современный сайт" или "удобное приложение" – это не ТЗ. Такие формулировки неизбежно приведут к недопониманиям и дополнительным расходам. Разработчик сделает "современно" по своему разумению, что может не совпадать с вашим.
  • **Отсутствие ТЗ:** Некоторые студии предлагают работать без ТЗ, обещая "гибкий подход". Это может быть удобно на старте, но принесет много проблем в дальнейшем, когда возникнут споры о функционале или сроках. В лучшем случае, ТЗ должно быть частью договора или приложением к нему.
  • **Неучтенные детали:** Забыли указать в ТЗ, что нужна интеграция с 1С? Это будет дополнительная работа и дополнительные расходы.

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

2. Сроки, этапы и порядок сдачи-приемки работ

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

**Что должно быть в этом разделе:**

  • **Общий срок проекта:** От старта до финальной сдачи.
  • **Этапы разработки:** Проект должен быть разбит на логические этапы (анализ, прототипирование, дизайн, фронтенд, бэкенд, тестирование, запуск). Для каждого этапа должны быть указаны сроки.
  • **Порядок сдачи-приемки:** Как будут сдаваться и приниматься этапы и проект в целом? Как фиксируются замечания? Сколько времени дается на их устранение?
  • **Условия переноса сроков:** В каких случаях сроки могут быть перенесены (например, задержка со стороны заказчика с предоставлением информации, утверждением макетов).

**Подводные камни:**

  • **"Плавающие" сроки:** Если в договоре указаны только общие сроки без этапов, контролировать ход проекта будет сложно. Вы рискуете получить готовый продукт в последний момент и без возможности внести корректировки.
  • **Сложности с приемкой:** Если не прописан четкий механизм приемки, могут возникнуть споры. Что считать принятым этапом? Как фиксировать доработки?
  • **Задержки со стороны заказчика:** Часто заказчики сами становятся причиной задержек, не предоставляя контент, доступы или не утверждая макеты вовремя. Хороший договор должен предусматривать, что такие задержки влияют на общий срок проекта.

**Пример реалистичных сроков (усредненный проект):**

| Этап разработки | Средний срок (рабочие дни) | Комментарий |

| :------------------------ | :------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

| Анализ и прототипирование | 10-20 | Зависит от сложности проекта, проработки ТЗ. |

| Дизайн (UI/UX) | 15-30 | Разработка концепции, макетов страниц. Может быть итеративным. |

| Фронтенд-разработка | 20-40 | Верстка страниц, адаптация под разные устройства. |

| Бэкенд-разработка | 30-60 | Разработка логики, базы данных, интеграций. Самый трудоемкий этап. |

| Тестирование | 10-20 | Функциональное, нагрузочное, кроссбраузерное. |

| Запуск и настройка | 5-10 | Развертывание на сервере, настройка доменов, SSL. |

| **ИТОГО** | **90-180+** | **От 4 до 8+ месяцев. Проекты с ИИ-интеграциями или сложной логикой могут занимать существенно больше времени. Срочные проекты (2-3 месяца) всегда дороже и имеют риски.** |

3. Стоимость, порядок оплаты и гарантии

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

**Что должно быть в этом разделе:**

  • **Общая стоимость проекта:** Фиксированная цена или почасовая оплата (тайм-энд-материалс). Для малого и среднего бизнеса чаще предпочтительна фиксированная цена.
  • **Порядок оплаты:** Обычно это поэтапная оплата (предоплата за каждый этап). Например, 30% предоплата, 30% после дизайна, 40% после сдачи.
  • **Что входит в стоимость:** Четкий перечень работ, включенных в указанную сумму.
  • **Что не входит в стоимость:** Например, покупка домена, хостинга, платных плагинов, контент-менеджмент, услуги сторонних сервисов (API).
  • **Порядок изменения стоимости:** Как будут оплачиваться дополнительные работы, которые не были предусмотрены ТЗ.
  • **Гарантийный период:** Срок, в течение которого разработчик бесплатно устраняет ошибки, выявленные после запуска. Обычно 1-3 месяца.
  • **Порядок расторжения договора:** Условия, при которых любая из сторон может расторгнуть договор, и финансовые последствия такого расторжения.

**Подводные камни:**

  • **Самая низкая цена:** Слишком низкая цена часто означает, что разработчик что-то недооценил или планирует экономить на качестве. В итоге это выльется в допработы или некачественный продукт.
  • **Отсутствие гарантийного периода:** После запуска всегда могут выявиться мелкие баги. Если гарантии нет, за их исправление придется платить.
  • **Нечеткий порядок допработ:** Если вы решите добавить функционал, который не был в ТЗ, это должно быть оформлено как дополнительное соглашение с указанием стоимости и сроков.
  • **Нереалистичные бюджеты (2026 год, РФ):**

| Тип проекта | Ориентировочный бюджет (руб.) | Комментарий |

| :--------------------------------------------- | :---------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

| Лендинг (одностраничный сайт) | 150 000 – 400 000 | Простой дизайн, базовая адаптивность, форма обратной связи. Без сложной логики. |

| Корпоративный сайт (5-15 страниц) | 400 000 – 1 200 000 | Уникальный дизайн, CMS, адаптивность, формы, галереи, новости, блог. |

| Интернет-магазин (средний) | 800 000 – 2 500 000 | Каталог товаров, корзина, личный кабинет, платежные системы, интеграция с 1С/МойСклад. |

| Веб-сервис / сложное веб-приложение | От 2 000 000 – 7 000 000+ | Уникальный функционал, сложные расчеты, несколько типов пользователей, API, высокая нагрузка. |

| Мобильное приложение (iOS/Android, MVP) | От 2 500 000 – 6 000 000+ | Минимально жизнеспособный продукт (MVP) с базовым функционалом. Для нативного приложения стоимость может быть в 2 раза выше (отдельно под iOS и Android). |

| Интеграция ИИ в бизнес-процессы (чат-бот/аналитика) | От 500 000 – 3 000 000+ | Зависит от сложности задачи. Например, готовый AI-сотрудник для ответов клиентам будет стоить значительно дешевле, чем разработка кастомного ИИ-решения для анализа большого объема данных и прогнозирования. Если речь о готовых решениях, то оплата может быть помесячной.

**Наш совет:** Убедитесь, что в договоре четко прописаны условия получения прав на интеллектуальную собственность (сайт, приложение, исходники). Иначе вы рискуете заплатить за разработку и не иметь полных прав на нее.

4. Права и обязанности сторон: что должен каждый

Четкое описание прав и обязанностей обеих сторон – залог успешного сотрудничества.

**Что должно быть в этом разделе:**

  • **Обязанности Заказчика:** Предоставление информации, контента, своевременное утверждение этапов, оплата.
  • **Обязанности Исполнителя:** Выполнение работ в соответствии с ТЗ и сроками, обеспечение качества, предоставление отчетов.
  • **Права Заказчика:** Контролировать ход работ, требовать выполнения ТЗ, получать отчеты, владеть правами на результат.
  • **Права Исполнителя:** Получать оплату, требовать предоставления информации, запрашивать утверждение этапов.
  • **Конфиденциальность:** Условия неразглашения информации о проекте и бизнесе заказчика.
  • **Форс-мажор:** Что делать в случае непредвиденных обстоятельств (стихийные бедствия, военные действия и т.д.).

**Подводные камни:**

  • **Неясные обязанности:** Если не прописано, кто за что отвечает, неизбежны конфликты. Например, кто предоставляет хостинг? Кто регистрирует домен? Кто наполняет сайт контентом?
  • **Отсутствие отчетности:** Вы должны иметь возможность контролировать процесс. Договор может предусматривать регулярные отчеты или демонстрации промежуточных результатов.
  • **Проблема с авторскими правами:** Убедитесь, что договор предусматривает передачу вам исключительных прав на разработанный продукт. Иначе студия может использовать ваш сайт/приложение в своих целях или продать его конкурентам.

5. Ответственность сторон и разрешение споров

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

**Что должно быть в этом разделе:**

  • **Штрафы и неустойки:** За нарушение сроков (как со стороны исполнителя, так и заказчика), за невыполнение обязательств.
  • **Ограничение ответственности:** Например, студия не несет ответственности за сбои на хостинге, если хостинг выбирал заказчик.
  • **Порядок разрешения споров:** Претензионный порядок (обязательная попытка решить спор путем переговоров), а затем обращение в суд (с указанием суда).
  • **Применимое право:** Законодательство какой страны или региона будет применяться.

**Подводные камни:**

  • **Отсутствие штрафов:** Если нет никаких санкций за нарушение сроков, у исполнителя может не быть мотивации торопиться.
  • **Нереалистичные штрафы:** Слишком высокие штрафы могут отпугнуть хороших исполнителей.
  • **Размытые формулировки:** "В случае возникновения споров стороны приложат все усилия для их урегулирования" – это не работает. Нужен четкий механизм.

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

Что такое MVP и почему это важно для моего бизнеса?

MVP (Minimum Viable Product) – это минимально жизнеспособный продукт, версия вашего сайта или приложения с базовым, но достаточным функционалом, чтобы решить основную проблему пользователя. Запуск MVP позволяет быстрее выйти на рынок, собрать обратную связь от реальных пользователей и уже на ее основе развивать продукт. Это помогает сэкономить бюджет и снизить риски, так как вы не вкладываете все деньги в продукт, который может оказаться невостребованным.

Могу ли я сэкономить, если сам напишу ТЗ?

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

Что делать, если студия предлагает работать без договора?

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

---

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

Что дальше

Не знаете, с чего начать? Закажите бесплатный [разбор задачи](/razbor) — оценим сроки и бюджет и честно скажем, где можно сэкономить.

**Читайте также:**

  • [Как оценить стоимость IT-проекта до ТЗ: Руководство для бизнеса](/blog/kak-ocenit-stoimost-it-proekta-do-tz-rukovodstvo-dlya-biznesa)
  • [Фиксированная цена или почасовая оплата: как выгоднее заказывать разработку](/blog/fiksirovannaya-cena-ili-pochasovaya-oplata-kak-vygodnee-zakazyvat-razrabotku)
  • [Как принимать работу у подрядчика по разработке: чек-лист для бизнеса](/blog/kak-prinimat-rabotu-u-podryadchika-po-razrabotke-chek-list-dlya-biznesa)

Все статьи