Перейти к содержимому

Сразу комплектом

Договор на разработку сайта или приложения — пакет документов от ТЗ до приёмки

Обновлено:

Разработка сайта или приложения = многомесячный проект с подвижным scope, промежуточными релизами, передачей кода. Минимальный пакет здесь — не 4 документа, а 6-8: от NDA до договора передачи исключительных прав. Без них клиент может отказаться от приёмки, а вы — потерять права на код. Dokli связывает их в одну версию с проверкой согласованности. [Начать IT-пакет →]

15 разделов·Что внутри страницы
  1. 01Что входит в IT-пакет разработки
  2. 02Чем отличается от пакетов «договор + ТЗ + акт» и agency-комплекта
  3. 03Передача исключительных прав на код
  4. 04Гарантия на код
  5. 05Acceptance Criteria
  6. 06Промежуточные акты по этапам
  7. 07Особенности для самозанятого
  8. 08Особенности для ИП
  9. 09Связанные документы
  10. 10Связанные сценарии
  11. 11Связанные пакеты
  12. 12Связанные аудитории
  13. 13Что Dokli даёт в IT-пакете
  14. 14Что Dokli не делает
  15. 15Частые вопросы

Что входит в IT-пакет разработки

  1. NDA — подписывается до обсуждения проекта (обязательно).
  2. Договор подряда на разработку — основной коммерческий документ. Не услуги — у разработки есть отделимый результат (код, дизайн).
  3. Техническое задание — приложение к договору. Детальное описание функциональности.
  4. Критерии приёмки (Acceptance Criteria) — отдельное приложение или раздел ТЗ. Конкретные условия, при которых задача / спринт / релиз считается принятым.
  5. График работ / Roadmap — приложение с этапами и сроками.
  6. Промежуточные акты — после каждого этапа / релиза.
  7. Финальный акт — после полной сдачи.
  8. Договор передачи исключительных прав или оговорка в основном договоре — кому принадлежит код после оплаты.
  9. Гарантийное соглашение (опц.) — на исправление багов в течение N месяцев после сдачи.

Чем отличается от пакетов «договор + ТЗ + акт» и agency-комплекта

  • Пакет «договор + ТЗ + акт» = простая разовая работа на пару (NDA + договор + ТЗ + акт).
  • Agency-комплект (договор + приложение + акт) = двойная цепочка с подрядчиками (8 документов).
  • IT-пакет (NDA + договор + ТЗ) = разработка с этапами, промежуточными релизами, передачей IP-прав. Главные отличия:
  • Поэтапные акты обязательны (нельзя один акт в конце на 6-месячный проект).
  • Acceptance Criteria прописаны явно (что значит «готово» для каждой задачи).
  • Передача IP-прав требует отдельного оформления (ст. 1234, 1235 ГК).
  • Гарантия на код — отдельный пункт, особенно для коммерческой разработки.

Передача исключительных прав на код

Если разработчик — штатный сотрудник заказчика, права на служебное произведение принадлежат заказчику автоматически.

Если разработчик — внешний подрядчик по договору подряда, права остаются у разработчика, если в договоре не указано иное.

Гарантия на код

Что обычно гарантируется:

  • Бесплатное исправление багов в течение N месяцев (обычно 3-6) после сдачи.
  • Бесплатное обновление зависимостей при критических уязвимостях.
  • Доступ к разработчику для консультаций (по часам или фиксировано).

Что НЕ гарантируется:

  • Совместимость с будущими версиями ОС / браузеров.
  • Адаптация под изменившиеся бизнес-требования.
  • Исправление ошибок в чужом коде, который заказчик дорабатывал сам.

Acceptance Criteria

Это формализованное «что значит готово». Без этого — приёмка превращается в субъективное «нравится / не нравится».

Шаблон AC для одной фичи: `` GIVEN [предусловие] WHEN [действие пользователя] THEN [ожидаемый результат] ``

Пример: `` GIVEN: пользователь не залогинен WHEN: открывает страницу /dashboard THEN: происходит редирект на /login с сохранением исходного URL ``

При приёмке проверка идёт по списку AC: всё ✅ = принято.

Промежуточные акты по этапам

Минимум 1 акт за этап. Этап = логическая часть проекта (auth, поиск, корзина, etc.) или sprint (2-недельный цикл).

Каждый промежуточный акт содержит:

  • Список фич / задач, выполненных в этапе.
  • Соответствие AC (отметка по каждому пункту).
  • Результат — ссылка на репозиторий с конкретным коммитом / тэгом.
  • Сумма за этап (по графику работ).

Преимущество поэтапных актов:

  • Деньги поступают чаще (cash flow).
  • Клиент не может развернуть в конце.
  • При спорах потеряется только этап, не весь проект.

Особенности для самозанятого

НПД работает для разработки. Чек выдаётся при оплате.

Лимит 2.4 млн ₽ годового дохода — критичен для крупных IT-проектов. Если проект больше 2 млн — лучше открыть ИП.

НПД и сложные права — самозанятый передаёт IP-права наравне с ИП. Юридически это не запрещено.

Налог за заказчика — если заказчик ООО, он не платит НДФЛ за вас (вы платите НПД сами). Это упрощает оформление по сравнению с ГПД с физ-лицом.

Особенности для ИП

Договор подряда стандартно. УСН-Доход 6% или УСН-Доход-Расход 15%.

На УСН-Доход-Расход: расходы на инфраструктуру (серверы, хостинг, инструменты) уменьшают налог.

НДС: при ОСН — стандартно начисляется. При УСН — без НДС, но крупные клиенты часто требуют НДС → вынуждены переходить на ОСН.

Хотите сразу к делу?

Dokli соберёт документ по этому сценарию с проверкой рисков перед выпуском.

Создать документ

Связанные документы

Связанные сценарии

Работа по этапам — основной режим.

Подключение подрядчика — если в проекте субподрядчики.

Связанные пакеты

Договор + ТЗ + акт — упрощённый вариант для разовых небольших проектов.

Договор + приложение + акт (agency) — для агентского распределения работ.

Связанные аудитории

Фрилансер — типичный кейс для соло-разработчика.

ИП — основной кейс для серьёзных IT-проектов.

Что Dokli даёт в IT-пакете

8 связанных документов в одной версии проекта.

Передача IP-прав автоматически прописана в договоре подряда (отлагательное условие после оплаты).

Acceptance Criteria — отдельный шаблон со структурой GIVEN/WHEN/THEN.

Промежуточные акты с авто-привязкой к этапам графика.

При scope-изменении — допсоглашение с обновлением ТЗ + AC + графика.

Что Dokli не делает

  • Не управляет git-репозиторием (вы публикуете коммиты сами).

  • Не отслеживает приёмку конкретных AC (это менеджер проекта).

  • Не делает ревью кода или архитектуры.

  • Не оформляет open-source лицензии (но даёт чек-лист их проверки).

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

Можно ли использовать только договор оказания услуг для разработки?

Технически можно, но рискованно. У разработки есть отделимый результат (код), значит должен быть подряд. Использование «услуг» создаёт риск переквалификации судом и проблем с передачей прав.

Что если клиент хочет «agile, без ТЗ»?

Объяснить: agile = adaptive scope, но **acceptance criteria каждой задачи** всё равно нужны. Без них любой sprint review превращается в «не нравится». Документируете каждый sprint backlog как мини-ТЗ.

Кому принадлежит код во время разработки?

Разработчику до оплаты + момента передачи прав. Это рычаг: не оплатил → не получил права. Прописывайте «отлагательное условие» в договоре.

Что с компонентами на open-source?

Перечислите все open-source библиотеки + их лицензии в приложении к договору. MIT и Apache 2.0 — без проблем коммерческое использование. GPL / AGPL — заражают ваш код, требует осторожности.

Acceptance Criteria — это обязательно?

Юридически нет, но без них приёмка субъективна. Реальная защита от scope creep — детализированные AC, не общие фразы.

Готовы перейти к документу?

Dokli соберёт документ по вашему сценарию с вопросами по делу и проверкой рисков перед выпуском.