Договор на разработку маркетплейса подписывают почти все, но читают внимательно единицы. Итог предсказуем: задержки на 3–6 месяцев, споры о том, кто владеет исходным кодом, и доработки за отдельные деньги, которые казались очевидными. Эта статья — практический разбор того, что должно быть в договоре, чтобы проект завершился в срок, в бюджете и с нужным результатом.
Почему стандартный шаблон договора не защищает заказчика
Большинство подрядчиков присылают типовой договор на оказание услуг или договор подряда на 3–4 страницы. В нём есть реквизиты, сумма и формальные сроки — и почти ничего о самом продукте. Проблема в том, что маркетплейс — это сложная система с десятками функциональных блоков: личные кабинеты продавцов и покупателей, платёжный шлюз, логистика, модерация, аналитика. Если техническое задание не является неотъемлемой частью договора, каждый спорный момент решается в пользу того, кто громче настаивает — чаще это подрядчик.
Второй риск — размытые критерии приёмки. Без чётких метрик («система выдерживает 500 одновременных пользователей», «время загрузки страницы товара не превышает 2 секунды») подрядчик сдаёт работу, когда считает нужным, а заказчик не имеет правовых оснований отказать в подписании акта.
Обязательные разделы договора на разработку маркетплейса
Ниже — минимальный набор разделов, без которых договор становится декларацией о намерениях.
Техническое задание как приложение
ТЗ должно быть подписано обеими сторонами и прямо упомянуто в теле договора как документ, имеющий равную юридическую силу. Хорошее ТЗ для маркетплейса включает: функциональные требования по ролям (покупатель, продавец, администратор), нефункциональные требования (производительность, безопасность, масштабируемость), описание интеграций (платёжные системы, службы доставки, CRM), макеты или ссылки на прототипы, стек технологий.
Этапы, сроки и промежуточные результаты
Разбейте разработку на этапы с фиксированными датами сдачи и конкретными deliverables. Типичная разбивка для маркетплейса:
- Аналитика и проектирование — 3–4 недели
- Дизайн UI/UX — 4–6 недель
- Разработка backend и API — 8–14 недель
- Разработка frontend и мобильного приложения — 6–10 недель
- Интеграции и тестирование — 3–5 недель
- Запуск и гарантийный период — 2–4 недели
Привяжите оплату к этапам, а не к календарным датам. Так у подрядчика есть финансовый стимул соблюдать сроки.
Права на результат интеллектуальной деятельности
Это самый часто игнорируемый пункт. По умолчанию исходный код является объектом авторского права и принадлежит разработчику, если иное прямо не указано в договоре. Пропишите, что исключительные права на исходный код, дизайн, базы данных и документацию переходят к заказчику в момент подписания финального акта и полной оплаты. Отдельно укажите, какие open-source компоненты используются и на каких лицензиях — это важно, если планируете продавать платформу как SaaS.
Критерии приёмки и порядок сдачи работ
Опишите процедуру: подрядчик передаёт доступы и уведомляет о готовности этапа → заказчик проводит приёмочное тестирование в течение N рабочих дней → фиксирует замечания в протоколе → подрядчик устраняет в течение M дней. Установите, что молчание заказчика дольше оговорённого срока приравнивается к приёмке — иначе проект может зависнуть на финальном акте бесконечно.
Гарантии и постгарантийная поддержка
Минимальный гарантийный срок для маркетплейса — 6 месяцев на критические баги (платёжный контур, авторизация, потеря данных). Пропишите SLA: время реакции на критический инцидент — не более 4 часов, время устранения — не более 24 часов. Постгарантийную поддержку лучше оформить отдельным сервисным соглашением с фиксированным ежемесячным объёмом часов.
Ответственность сторон и штрафные санкции
Договор без санкций — пожелание. Зафиксируйте неустойку за нарушение сроков этапов (обычно 0.1–0.5% от стоимости этапа за каждый день просрочки) и предельный размер ответственности подрядчика (как правило, не более стоимости договора). Симметрично пропишите ответственность заказчика за задержку предоставления материалов или обратной связи — это честно и снижает конфликты.
Что чаще всего упускают в договоре
| Упущенный пункт | Последствие |
|---|---|
| Нет порядка внесения изменений в ТЗ | Каждый новый экран — повод для доплаты без согласования |
| Нет условий расторжения | Сложно выйти из проекта без суда при смене подрядчика |
| Не указан стек технологий | Подрядчик выбирает удобный ему стек, который сложно поддерживать другой командой |
| Нет требований к документации | После сдачи проекта нет архитектурных схем и API-документации |
| Права на домен и хостинг не урегулированы | Инфраструктура оформлена на подрядчика, что создаёт зависимость |
Чек-лист перед подписанием договора
- ТЗ подписано и является приложением к договору
- Этапы, сроки и deliverables зафиксированы
- Оплата привязана к этапам, а не к датам
- Исключительные права на код и дизайн переходят к заказчику
- Прописаны критерии приёмки и процедура сдачи
- Установлен гарантийный срок и SLA
- Указан технологический стек
- Есть порядок внесения изменений в ТЗ (change request)
- Прописаны условия досрочного расторжения
- Домен, хостинг и аккаунты в сторонних сервисах оформлены на заказчика
Часто задаваемые вопросы
Можно ли начинать разработку без подписанного ТЗ?
Формально — можно, но это серьёзный риск. Без утверждённого ТЗ у сторон нет единого понимания объёма работ. На практике это приводит к тому, что подрядчик сдаёт MVP с минимальным функционалом, а заказчик ожидал полноценную платформу. Если подрядчик предлагает стартовать до готовности ТЗ, зафиксируйте хотя бы список функциональных блоков и перечень интеграций в виде предварительного приложения — и установите срок подготовки полного ТЗ.
Кому должен принадлежать исходный код после сдачи проекта?
По российскому законодательству (ГК РФ, часть IV) исключительное право на программу для ЭВМ возникает у автора — то есть у разработчиков подрядчика. Чтобы права перешли к вам, это нужно прямо прописать в договоре: «Исполнитель передаёт Заказчику исключительные права на результаты работ в полном объёме». Без этой формулировки вы получаете лицензию на использование, а не право собственности на код.
Что делать, если подрядчик срывает сроки?
Если в договоре прописаны неустойки и порядок фиксации просрочки, направьте письменную претензию с расчётом штрафа — это часто ускоряет работу эффективнее любых переговоров. Параллельно запросите актуальный статус по этапам и письменное подтверждение новых сроков. Если просрочка превышает 30% от оставшегося срока договора, рассмотрите расторжение с возвратом аванса за невыполненные этапы — при условии, что этот механизм закреплён в договоре.
Как выбрать подрядчика, с которым договор будет работать
Надёжный подрядчик сам предлагает детальный договор и не уклоняется от обсуждения прав на код, SLA и штрафных санкций. Если на этапе переговоров вам говорят «зачем такие сложности, мы всё сделаем хорошо» — это тревожный сигнал. Профессиональная команда понимает, что прозрачные условия защищают обе стороны.
Если вам нужна разработка маркетплейса под ключ с понятным договором, фиксированными этапами и передачей исходного кода в вашу собственность — обсудим проект. Позвоните по номеру +7 (977) 326-69-09 или оставьте заявку на странице arisweb.ru/kontakty — разберём ваш случай и подготовим коммерческое предложение с прозрачной структурой договора.