Договор на разработку ПО: что обязательно прописать

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

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

Почему договор в IT-проекте особенно важен

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

Ключевые разделы договора на разработку

Предмет договора и объём работ

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

Этапы и календарный план

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

Стоимость и порядок оплаты

Фиксированная цена или оплата по фактически затраченному времени.
Разбивка платежей по этапам: стартовый платёж и оплата после приёмки каждого этапа.
Что входит в цену: дизайн, тестирование, размещение на сервере, обучение сотрудников.
Что оплачивается отдельно: аренда сервера, домен, платные библиотеки, SMS и другие внешние сервисы.

Порядок приёмки

Этот раздел вызывает больше всего споров, поэтому пишите конкретно:

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

Управление изменениями

Новые идеи по ходу проекта — это нормально. Пропишите порядок: письменный запрос → исполнитель оценивает влияние на стоимость и сроки → заказчик утверждает → работа начинается. Это защищает обе стороны от устных «добавьте заодно и это».

Интеллектуальная собственность и исходный код

Кому и когда переходят права на исходный код и дизайн (часто — после полной оплаты).
Какие права получает заказчик на готовые модули исполнителя, если они используются.
Не мешают ли лицензии открытых библиотек использованию продукта заказчиком.
Где и в каком виде передаётся код.

Аккаунты, сервер и домен

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

Конфиденциальность и данные

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

Исправление ошибок и поддержка

В течение какого периода после сдачи ошибки исправляются бесплатно и в каком порядке? Поддержка — отдельная услуга? Что в неё входит: мониторинг сервера, обновления, небольшие доработки, порядок реагирования на обращения? Для систем, на которые бизнес опирается каждый день, например CRM/ERP, эти условия разумно оформить отдельным приложением или договором.

Расторжение

Что происходит, если сотрудничество прекращается досрочно: как оценивается выполненная работа, как передаются код и документация. Об этом никто не любит думать, но именно этот раздел защищает обе стороны.

Таблица: раздел договора и его смысл

Раздел	Что прописать	От чего защищает
Объём работ	Ссылка на ТЗ, что не входит	От спора «это тоже обсуждали»
Этапы	Результаты и календарный план	От бесконечного затягивания
Оплата	Платежи привязаны к этапам	От оплаты без работы и работы без оплаты
Приёмка	Порядок проверки и акт	От споров о том, что значит «готово»
Изменения	Письменный запрос и оценка	От неконтролируемого роста бюджета
Код и аккаунты	Права и передача доступов	От зависимости от одного исполнителя
Поддержка	Исправление ошибок и сервис	От ситуации «запустили и бросили»

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

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

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

Нужен ли договор для небольшого проекта?

Да, даже короткий договор или письменная договорённость фиксирует перечень работ, цену, сроки и порядок приёмки. Это удобно обеим сторонам.

Кто готовит договор?

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

Обязательно ли передавать мне исходный код?

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

UFLEX — IT-команда из Намангана. Ведём каждый проект по договорённости, где чётко прописаны перечень работ, этапы, порядок приёмки и условия поддержки. Разрабатываем сайты, приложения, Telegram-боты, CRM/ERP, складские и кассовые системы, размещаем их на сервере и сопровождаем, работаем удалённо с клиентами по всему Узбекистану. Чтобы заранее обсудить условия проекта, оставьте заявку или напишите нам в Telegram.