Заказать разработку сайта, приложения, личного кабинета, CRM, SaaS-сервиса или внутренней системы технически стало проще. Можно найти студию, фрилансера, команду разработки, договориться в мессенджере, оплатить аванс и ждать результат.
Но юридически IT-разработка часто ломается не на коде, а на договоре.
Заказчик хотел готовый продукт, а разработчик сделал «первую версию». Заказчик думал, что получает исходный код, а разработчик говорит, что код остается у него. Заказчик оплатил дизайн, backend и личный кабинет, но домен, хостинг, репозиторий и админка оформлены на подрядчика. Заказчик хочет сменить команду, а новая команда не может получить доступы, документацию и базу данных. Разработчик использовал чужие шаблоны, open source с непонятной лицензией или платные компоненты на своем аккаунте. В итоге проект вроде бы есть, но бизнес им не управляет.
Договор с IT-разработчиком нужен не для формальности. Он должен заранее ответить на практические вопросы: что именно разрабатывается, в какие сроки, по каким этапам, кто ставит задачи, как принимается результат, когда платится деньги, кому принадлежит код, кто передает исходники, кто отвечает за ошибки, где хранятся доступы, можно ли привлекать субподрядчиков, что происходит при расторжении и как заказчик сможет продолжить проект без текущего разработчика.
ZLATA LEGAL помогает предпринимателям, IT-проектам и компаниям во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России готовить и проверять договоры на разработку сайтов, приложений, SaaS-сервисов, CRM, личных кабинетов, Telegram-ботов, интеграций, внутренних IT-систем и цифровых продуктов.
Короткий ответ
Чтобы защитить заказчика, в договоре с IT-разработчиком нужно подробно описать результат разработки, техническое задание, этапы, сроки, стоимость, порядок оплаты, критерии приемки, передачу исходного кода, права на программу, доступы, документацию, open source и сторонние компоненты, конфиденциальность, персональные данные, ответственность, гарантийную поддержку и порядок расторжения.
Главный риск заказчика — заплатить за разработку, но не получить контроль над продуктом. Контроль — это не только работающий сайт на экране. Это права на результат, исходный код, репозиторий, домен, хостинг, база данных, админка, инструкции, аккаунты, ключи API, документация, история задач и возможность передать проект другой команде.
В договоре нельзя ограничиваться фразой «разработчик обязуется создать сайт». Нужно указать, какой сайт, с какими функциями, на какой технологии, какие страницы, какие интеграции, какие роли пользователей, какие данные, какие требования к безопасности, какие этапы, какие материалы предоставляет заказчик и что считается готовым результатом.
Если проект сложный, договор без технического задания почти не защищает заказчика. Без ТЗ спор быстро превращается в разговор: заказчик говорит «я хотел другое», разработчик отвечает «мы сделали то, что обсуждали».
Почему договор с разработчиком часто не работает
Многие договоры на IT-разработку выглядят как обычный договор подряда или оказания услуг. В нем есть стороны, цена, срок и общая фраза про разработку сайта или приложения. Но для IT этого мало.
В разработке важны детали: функционал, архитектура, стек, роли пользователей, интеграции, админка, база данных, тестирование, нагрузка, безопасность, дизайн, адаптивность, API, исходный код, права, доступы и порядок запуска.
Если эти детали не описаны, договор не отвечает на главный вопрос: что именно должен передать разработчик.
Проблема усиливается, если общение идет в Telegram, задачи ставятся голосовыми, дизайн меняется по ходу, заказчик не фиксирует замечания, а разработчик выставляет счета за «доработки», которые заказчик считал частью первоначальной цены.
Хороший договор не отменяет живую работу над продуктом. Но он задает рамку: что входит в проект, что является изменением объема, как фиксируются новые задачи и когда заказчик обязан платить.
Техническое задание
Техническое задание — основной документ для защиты заказчика.
В нем нужно описать не только красивый результат, но и функциональность. Какие страницы или экраны должны быть. Какие роли пользователей. Как работает регистрация. Что делает личный кабинет. Какие формы есть на сайте. Какие уведомления отправляются. Какие интеграции подключаются. Какие данные хранятся. Какие отчеты формируются. Как работает админка. Какие требования к дизайну, адаптивности, скорости, безопасности и браузерам.
Для небольшого сайта ТЗ может быть коротким. Для приложения, SaaS, маркетплейса, CRM или внутренней системы ТЗ должно быть детальнее.
Важно, чтобы ТЗ было приложением к договору, а не просто перепиской в мессенджере. Переписка тоже может быть доказательством, но рабочее приложение к договору сильно удобнее.
Если заказчик сам пока не понимает продукт, можно разделить проект на этап аналитики и этап разработки. Сначала разработчик готовит прототип, описание функций, структуру данных и оценку, а уже потом стороны согласуют разработку.
Этапы разработки
Разработку лучше делить на этапы.
Например: аналитика и ТЗ, прототип, дизайн, frontend, backend, личный кабинет, интеграции, тестирование, запуск, документация и гарантийный период.
Для каждого этапа нужно указать результат, срок, стоимость и порядок приемки.
Это защищает обе стороны. Заказчик не платит всю сумму вперед за неопределенный результат. Разработчик понимает, что именно нужно сдать на каждом этапе. Если проект остановится, будет видно, что уже сделано и оплачено.
Главная ошибка — большой аванс за весь проект без четких этапов. Если разработчик пропадает или конфликтует, заказчик остается с частичной разработкой, которую сложно оценить, принять и передать другой команде.
Оплата
Оплата должна быть связана с результатом.
Для заказчика безопаснее платить по этапам: аванс на старт, затем оплата после сдачи и приемки конкретных частей. Для небольших задач допустима предоплата, но для серьезной разработки лучше не отдавать весь бюджет сразу.
В договоре нужно указать, что входит в стоимость: разработка, дизайн, верстка, backend, тестирование, интеграции, документация, передача исходного кода, настройка сервера, запуск, гарантийные исправления.
Также нужно отдельно определить, что считается дополнительной работой. Если заказчик меняет концепцию, добавляет новые функции, просит интеграцию, которой не было в ТЗ, или меняет дизайн после согласования, это может быть отдельная оплата. Но разработчик не должен называть «доработкой» то, что изначально входило в ТЗ.
Исходный код
Исходный код — один из главных активов заказчика.
Работающий сайт или приложение без исходного кода может стать ловушкой. Пока текущий разработчик на связи, все выглядит нормально. Но если он исчез, поднял цену, поссорился с заказчиком или отказался передавать проект, новая команда не сможет нормально поддерживать продукт.
В договоре нужно прямо указать, что разработчик передает заказчику исходный код, структуру проекта, репозиторий, инструкции по сборке и развертыванию, документацию, доступы и иные материалы, необходимые для использования, поддержки и развития продукта.
Также нужно определить момент передачи. Например, код передается по каждому этапу в репозиторий заказчика или в конце проекта после оплаты соответствующего этапа. Для заказчика безопаснее, когда репозиторий создается на его стороне с самого начала, а разработчик получает доступ как исполнитель.
Репозиторий
Репозиторий должен контролировать заказчик.
GitHub, GitLab, Bitbucket или другой репозиторий лучше создавать на аккаунте заказчика или компании заказчика. Разработчик получает права доступа, но не является единственным владельцем проекта.
Если репозиторий находится на личном аккаунте разработчика, заказчик зависит от него. Разработчик может закрыть доступ, удалить историю, не передать ветки, не дать настройки CI/CD или просто исчезнуть.
В договоре стоит указать, что исходный код ведется в согласованном репозитории, доступ к которому имеет заказчик, а передача результата включает актуальную версию кода, историю изменений, конфигурационные файлы без раскрытия секретов в открытом виде, инструкции по запуску и сведения о зависимостях.
Права на программу
Заказчик должен понимать, какие права он получает.
В IT-разработке важно не просто получить файлы. Нужно получить права на использование результата. Если заказчик планирует использовать продукт в своем бизнесе, развивать его, продавать доступ, передавать другой команде, масштабировать SaaS или привлекать инвестиции, вопрос прав критичен.
В договоре нужно указать, кому принадлежит исключительное право на созданную программу, дизайн, интерфейс, базу данных, документацию, тексты и иные результаты. Если права переходят заказчику, нужно определить момент перехода: после оплаты этапа, после подписания акта, после полной оплаты проекта или по иной модели.
Также важно указать территорию, срок, способы использования, право модификации, доработки, распространения, предоставления доступа третьим лицам, коммерческого использования и передачи прав.
Для заказчика обычно безопаснее закрепить, что исключительные права на специально созданный результат переходят к нему в полном объеме после оплаты соответствующего результата.
Не все права переходят автоматически
Распространенная ошибка заказчика — думать, что если он оплатил разработку, то «всё мое».
В целом для программы, созданной по заказу, закон дает заказчику сильную позицию, если договором не предусмотрено иное. Но в реальном договоре разработчик может прописать обратное: код остается за ним, заказчик получает только ограниченную лицензию, нельзя менять продукт, нельзя передавать другой команде, нельзя использовать в других проектах.
Поэтому договор нужно читать внимательно. Особенно разделы «Интеллектуальные права», «Лицензия», «Исключительные права», «Ограничения использования», «Портфолио», «Сторонние компоненты».
Если права написаны туманно, заказчик может оплатить разработку, но получить только право пользоваться продуктом в узких пределах.
Дизайн, тексты и интерфейс
IT-проект — это не только код.
В него могут входить дизайн-макеты, логотипы, иконки, иллюстрации, тексты, структура страниц, интерфейс, база данных, документация, презентации, брендовые элементы, шаблоны писем и админка.
В договоре нужно указать, что права переходят не только на программный код, но и на все результаты, созданные разработчиком или привлеченными им исполнителями в рамках проекта.
Если дизайн делает отдельный дизайнер, а тексты — копирайтер, нужно убедиться, что разработчик получил у них права и может передать их заказчику. Иначе через год может выясниться, что часть интерфейса или материалов принадлежит не заказчику и даже не студии, а отдельному фрилансеру.
Субподрядчики и команда разработчика
Разработчик может привлекать дизайнеров, верстальщиков, backend-разработчиков, DevOps, тестировщиков, аналитиков и других специалистов.
Для заказчика это нормально, если ответственность остается на основном исполнителе. Но нужно прописать, что разработчик отвечает за действия своей команды и субподрядчиков, а также гарантирует получение прав на все результаты, созданные ими для проекта.
Иначе заказчик заключил договор со студией, студия передала часть работы фрилансеру, фрилансер не передал права студии, а проблема прилетает заказчику.
В договоре можно указать, что привлечение субподрядчиков допускается только при сохранении ответственности разработчика и обязанности обеспечить передачу прав заказчику.
Open source и сторонние компоненты
Современная разработка почти всегда использует готовые библиотеки, фреймворки, шаблоны, плагины, open source, API, SDK и платные компоненты.
Это нормально. Ненормально — когда заказчик не знает, что именно встроено в продукт и на каких условиях.
В договоре нужно указать, что разработчик вправе использовать сторонние компоненты только при условии, что это не нарушает права третьих лиц и не ограничивает заказчика в использовании продукта по назначению. Желательно получить перечень ключевых сторонних компонентов и лицензий.
Особенно осторожно нужно относиться к компонентам, которые требуют раскрытия исходного кода, запрещают коммерческое использование, ограничивают модификацию или привязаны к аккаунту разработчика.
Если проект коммерческий, SaaS или планируется продажа инвестору, чистота прав на код становится важной частью стоимости продукта.
Платные сервисы и аккаунты
Разработка часто зависит от внешних сервисов: хостинг, домен, SSL, SMS, email, карты, платежи, CDN, облако, аналитика, API, App Store, Google Play, GitHub, Figma, Tilda, CMS, плагины, конструкторы, лицензии и подписки.
Заказчику нужно заранее определить, на чьих аккаунтах все это оформляется.
Для ключевых активов безопаснее использовать аккаунты заказчика. Домен, хостинг, репозиторий, платежный агрегатор, магазины приложений, облако и аналитика не должны висеть на личной почте разработчика.
В договоре нужно указать, какие аккаунты создает заказчик, какие настраивает разработчик, кто оплачивает подписки, кто хранит доступы, что передается после завершения проекта и как происходит смена подрядчика.
Домен и хостинг
Для сайта домен и хостинг — базовые активы.
Если домен зарегистрирован на разработчика, заказчик фактически не контролирует свой сайт. Если хостинг на аккаунте студии, заказчик зависит от ее доброй воли. Если доступ к DNS только у подрядчика, даже перенос сайта может стать конфликтом.
Домен должен быть оформлен на заказчика или его компанию. Хостинг, облако и серверы лучше оформлять так, чтобы заказчик имел полный административный доступ.
В договоре нужно указать, что разработчик обязан передать все доступы, настройки, резервные копии, инструкции и сведения, необходимые для самостоятельного управления сайтом или передачи его другому подрядчику.
Доступы и пароли
Доступы нужно регулировать не менее внимательно, чем деньги.
Кто имеет доступ к админке, серверу, базе данных, репозиторию, домену, хостингу, аналитике, платежному кабинету, CRM, почте, API, облаку, магазинам приложений и мессенджерам.
Доступы должны выдаваться персонально и по роли. Не стоит передавать общий пароль в чат. После окончания работ доступы подрядчика нужно отозвать, а ключевые пароли сменить.
В договоре можно указать, что разработчик обязан соблюдать конфиденциальность доступов, не передавать их третьим лицам, использовать безопасные способы хранения, немедленно сообщать об инцидентах и вернуть или удалить доступы после окончания договора.
Персональные данные
Если разработчик получает доступ к базе пользователей, заявкам, CRM, личному кабинету, платежам, логам, документам или аккаунтам, он обрабатывает персональные данные.
В договоре нужно оформить поручение обработки персональных данных или отдельный блок о данных: какие данные доступны разработчику, для каких задач, какие действия он может совершать, как защищает данные, может ли использовать реальные данные в тестовой среде, когда удаляет копии и что делает при инциденте.
Лучше не давать разработчику реальные данные там, где можно использовать тестовые или обезличенные.
Особенно важно это для сайтов и сервисов с заявками, подписками, личными кабинетами, маркетплейсами, B2B-данными, документами, платежами и чувствительными темами.
Конфиденциальность
Заказчик может передавать разработчику бизнес-информацию: идею продукта, клиентские данные, финансовую модель, внутренние процессы, логику ценообразования, интеграции, документы, коммерческие предложения, базы и планы запуска.
В договоре должен быть раздел о конфиденциальности. Разработчик не должен использовать информацию заказчика для своих проектов, передавать ее конкурентам, публиковать скриншоты без разрешения, показывать закрытый функционал в портфолио или обсуждать проект публично.
Если проект чувствительный, можно отдельно подписать NDA или усиленный раздел о коммерческой тайне. Но даже обычный договор должен содержать рабочие правила конфиденциальности.
Приемка работ
Приемка — один из самых важных блоков договора.
Нужно указать, как разработчик сдает результат, в какой среде, какие материалы передает, сколько времени заказчик проверяет, как направляет замечания, сколько времени разработчик их исправляет, что считается недостатком, что считается новой задачей и когда подписывается акт.
Для IT-проекта лучше принимать не только «визуально работает», а по критериям: функционал из ТЗ, тестовые сценарии, адаптивность, интеграции, доступы, код в репозитории, документация, инструкции, отсутствие критических ошибок.
Если заказчик подписал акт без замечаний, потом сложнее ссылаться на явные недостатки, которые можно было обнаружить при обычной проверке. Поэтому приемку нельзя делать формально.
Тестирование
Тестирование нужно включать в договор или ТЗ.
Кто тестирует продукт. На каких устройствах и браузерах. Какие сценарии проверяются. Кто готовит тест-кейсы. Как фиксируются ошибки. Какие ошибки являются критическими. Можно ли запускать продукт с некритическими багами. Сколько времени дается на исправление.
Для сайта-визитки тестирование может быть простым. Для приложения, маркетплейса, SaaS, CRM или платежного сервиса без тестирования запускать продукт опасно.
Важно разделять баги и новые пожелания. Баг — это когда функция из ТЗ работает неправильно. Новое пожелание — это когда заказчик хочет изменить или добавить то, чего в ТЗ не было.
Гарантийный период
После запуска почти всегда появляются ошибки.
Поэтому в договоре нужен гарантийный период: например, разработчик исправляет ошибки, связанные с выполненными им работами, в течение определенного срока после приемки или запуска.
Важно описать, что входит в гарантию. Исправление багов — да. Новые функции — нет. Изменения из-за обновления стороннего API — по ситуации. Ошибки из-за действий заказчика или другого подрядчика — отдельно. Сбои хостинга или платежного агрегатора — не всегда зона ответственности разработчика.
Без гарантийного периода заказчик может принять проект, а через неделю получить ответ: «Это уже поддержка, оплачивайте отдельно».
Поддержка и сопровождение
Разработка и поддержка — разные вещи.
Договор на разработку должен описывать создание продукта. После запуска может понадобиться отдельное сопровождение: обновления, исправления, мониторинг, резервные копии, сервер, безопасность, мелкие доработки, консультации, реакция на инциденты.
Если поддержка включена в цену, нужно указать срок, объем часов, каналы связи и время реакции. Если не включена — лучше прямо написать, что сопровождение оформляется отдельно.
Это защищает заказчика от неожиданного отказа в помощи, а разработчика — от бесконечных бесплатных задач после запуска.
Сроки
Сроки в IT-разработке нужно привязывать к этапам и действиям сторон.
Разработчик не может сделать дизайн без материалов заказчика, интеграцию без доступов, платежи без аккаунта агрегатора, приложение без аккаунта магазина, личный кабинет без согласованной логики ролей.
Поэтому договор должен учитывать, какие материалы и доступы предоставляет заказчик и как их задержка влияет на сроки.
Но разработчик тоже не должен бесконечно ссылаться на «сложность разработки». Для каждого этапа должны быть сроки, порядок переноса, уведомления о задержке и последствия нарушения.
Изменение объема работ
В IT-проектах заказчик часто меняет идею по ходу разработки. Это нормально, если есть процедура.
Нужно указать, как оформляются изменения: заявка, оценка сроков и стоимости, подтверждение заказчика, включение в следующий этап или отдельная оплата.
Без этой процедуры конфликт почти гарантирован. Заказчик считает изменение мелкой правкой, разработчик считает новой функцией. Разработчик делает доработку, а потом выставляет счет, который заказчик не ожидал. Или наоборот: заказчик просит много дополнительных функций, а разработчик не может объяснить, почему сроки и цена выросли.
Правило простое: новая функция — через согласование изменения объема.
Ответственность разработчика
Ответственность должна быть не декоративной.
Можно предусмотреть неустойку за нарушение сроков, обязанность исправить недостатки, ответственность за нарушение прав третьих лиц, утечку данных, потерю доступа, непередачу исходного кода, нарушение конфиденциальности и отказ передать результаты после оплаты.
Для заказчика особенно важны рычаги: удержание части оплаты до передачи результата, поэтапная оплата, право требовать исходники, право расторгнуть договор при существенном нарушении, обязанность передать незавершенный результат в актуальном состоянии.
При этом ответственность должна быть реалистичной. Слишком огромные штрафы могут выглядеть красиво, но не всегда помогают практически. Лучше иметь рабочие механизмы контроля и приемки.
Что делать, если разработчик пропал
Договор должен предусматривать сценарий, когда разработчик исчез, затягивает сроки или отказывается передавать результат.
Заказчику важно иметь доступ к репозиторию, домену, хостингу, серверу, базе, дизайну, задачам и документации. Тогда даже при конфликте можно передать проект другой команде.
Если все находится у разработчика, заказчик сначала вынужден бороться за доступы, а уже потом за продукт.
В договоре можно закрепить обязанность регулярно передавать актуальные результаты, вести код в репозитории заказчика, обновлять документацию, передавать доступы и не удерживать результат при споре сверх согласованных условий.
Расторжение договора
Расторжение нужно описать заранее.
Что происходит, если заказчик отказался от проекта. Что происходит, если разработчик нарушил сроки. Какие этапы оплачиваются. Какие материалы передаются. Переходят ли права на частично созданный результат. Возвращается ли аванс. В каком состоянии передается код. Когда закрываются доступы.
Если этого нет, при конфликте каждая сторона будет трактовать ситуацию в свою пользу.
Для заказчика важно, чтобы при оплате этапа он получал результат и права на него. Тогда даже при расторжении проект не обнуляется.
Документация
Документация часто кажется вторичной, пока не нужно менять разработчика.
Для сайта или сервиса нужна хотя бы минимальная документация: как развернуть проект, где находится код, какие зависимости, какие переменные окружения, какие интеграции, как устроена база, как запускать миграции, как делать резервные копии, как работать с админкой, где находятся ключи API, какие сервисы подключены.
Для сложного продукта нужна техническая документация, описание API, структура ролей, сценарии пользователя, инструкции администратора и схема интеграций.
В договоре нужно указать, что документация является частью результата. Иначе разработчик может сказать: «Мы код передали, остальное не входило».
Безопасность
Если продукт работает с пользователями, платежами, личным кабинетом, B2B-данными или документами, требования к безопасности нужно включать в ТЗ.
Например, авторизация, роли доступа, защита админки, хранение паролей, резервное копирование, логирование, защита от базовых уязвимостей, SSL, ограничение доступа к серверу, безопасная работа с ключами API, отсутствие секретов в репозитории, обработка ошибок, права администраторов.
Не нужно превращать небольшой сайт в банковскую систему. Но базовые требования должны быть. Особенно если проект собирает персональные данные или принимает оплату.
Интеграции
Интеграции часто становятся источником споров.
Платежный агрегатор, CRM, 1С, склад, доставка, карты, SMS, email, Telegram, API банка, ЭДО, маркетплейсы, аналитика, внешние базы — все это требует доступов, настроек и тестирования.
В ТЗ нужно описать, какие интеграции входят в проект, кто предоставляет доступы, кто оплачивает внешние сервисы, что считается успешной интеграцией, кто отвечает, если внешний сервис изменил API или не работает.
Если интеграция не описана, разработчик может считать ее отдельной задачей, а заказчик — очевидной частью проекта.
Мобильное приложение
Для мобильного приложения есть отдельные риски.
Нужно определить, кто владеет аккаунтами App Store и Google Play, кто готовит сборки, кто публикует приложение, кто проходит модерацию, кто отвечает за требования площадок, кто хранит сертификаты, ключи подписи, push-настройки и доступы.
Если аккаунт магазина оформлен на разработчика, заказчик может потерять контроль над приложением.
В договоре нужно указать, что ключевые аккаунты и сертификаты должны быть переданы заказчику или созданы на его стороне. Также нужно описать, что происходит, если магазин отклонил приложение по причинам, связанным с требованиями площадки, контентом заказчика или ошибками разработчика.
Сайт на конструкторе
Если сайт делается на Tilda, WordPress, Webflow, Битрикс, другой CMS или конструкторе, договор все равно нужен.
Нужно определить, кому принадлежит аккаунт, кто оплачивает тариф, какие шаблоны и плагины используются, есть ли лицензии, можно ли перенести сайт, передаются ли доступы, кто отвечает за обновления и безопасность.
Сайт на конструкторе может выглядеть простым, но если аккаунт оформлен на подрядчика, заказчик снова зависит от него.
Для заказчика безопаснее, когда домен, конструктор, хостинг, плагины и аналитика оформлены на него, а разработчик только настраивает и передает результат.
No-code и low-code
No-code и low-code сервисы тоже требуют юридической проверки.
Если продукт собран на готовой платформе, заказчик должен понимать ограничения: можно ли выгрузить данные, перенести проект, получить исходный код, сменить подрядчика, использовать коммерчески, масштабировать, подключить свой домен, соблюдать требования по персональным данным.
Договор должен честно описывать, что именно создается: собственная разработка, настройка платформы, конфигурация конструктора, интеграция готовых сервисов или смешанная модель.
Иначе заказчик может думать, что получает уникальный продукт, а фактически получает набор настроек в чужой системе.
Налоги и статус исполнителя
Перед договором нужно проверить, кто разработчик: ООО, ИП, самозанятый, физическое лицо, студия, агентство или иностранный подрядчик.
От этого зависят документы, налоги, закрывающие акты, НДС, платежи, ответственность и возможность нормально передать права.
Если разработчик — физическое лицо или самозанятый, нужно особенно аккуратно оформлять передачу исключительных прав и вознаграждение. Если разработчик — студия, нужно смотреть, кто фактически создает код и переданы ли права внутри команды.
Для заказчика важно, чтобы платежи, акты и права были оформлены так, чтобы потом продукт можно было показать инвестору, банку, партнеру или в суде.
Проверка разработчика до договора
До оплаты стоит проверить разработчика.
Кто юридическое лицо или ИП. Есть ли портфолио. Кто будет в команде. Где ведется код. Как оформляются права. На чьих аккаунтах домен, хостинг и репозиторий. Есть ли опыт похожих проектов. Кто отвечает за дизайн, backend, frontend, DevOps и тестирование. Как устроена поддержка после запуска. Какие сторонние компоненты используются. Как передаются доступы и документация.
Не нужно превращать проверку в допрос. Но если разработчик раздражается от вопросов про права, исходный код и репозиторий, это сигнал.
Что нельзя делать заказчику
Нельзя платить весь бюджет вперед без этапов. Нельзя начинать разработку без ТЗ. Нельзя оформлять домен, хостинг, репозиторий и магазины приложений на разработчика. Нельзя принимать работу без проверки. Нельзя подписывать акт, если есть явные критические недостатки. Нельзя оставлять права на код туманными. Нельзя соглашаться на «код наш, вы просто пользуетесь», если бизнесу нужен собственный продукт. Нельзя давать разработчику реальные персональные данные без правил. Нельзя вести все договоренности только в мессенджере. Нельзя забывать про документацию и передачу доступов.
Главная ошибка заказчика — считать, что контроль появится после оплаты. На практике контроль нужно закладывать до старта.
Как правильно выстроить договор
Сначала нужно описать продукт и цель разработки. Затем подготовить техническое задание или провести этап аналитики. После этого определить этапы, сроки, стоимость и порядок оплаты. Отдельно закрепить права на результат, передачу исходного кода, репозиторий, документацию, доступы, сторонние компоненты, персональные данные и конфиденциальность.
Затем нужно прописать приемку: как сдается этап, сколько времени заказчик проверяет, как фиксируются замечания, что является багом, что является новой задачей, когда подписывается акт и что происходит при уклонении от приемки.
После этого можно запускать разработку. В процессе важно фиксировать изменения, хранить переписку, вести задачи в трекере, принимать этапы документально и не терять контроль над аккаунтами.
Локальный аспект: Владивосток, Приморье и Дальний Восток
Во Владивостоке и Приморском крае бизнес все чаще заказывает не просто сайты, а прикладные цифровые решения: CRM, личные кабинеты, сервисы для логистики, ВЭД, поставок из Китая, складов, заявок, морской отрасли, сервисного ремонта, B2B-платформ, Telegram-ботов и внутренних учетных систем.
Такие проекты часто начинаются не как большой IT-стартап, а как практическая задача: директору нужна таблица, менеджерам — учет заявок, клиентам — личный кабинет, бухгалтерии — документы, складу — статусы, партнерам — доступ к заказам.
Именно здесь договор с разработчиком особенно важен. Если проект нужен для операционной деятельности, потеря доступа к коду, базе, серверу или подрядчику может остановить не «сайт», а бизнес-процесс.
Для регионального бизнеса лучше сразу оформлять разработку так, чтобы продукт можно было поддерживать, передавать другой команде, масштабировать и юридически показывать партнерам или инвесторам.
Как ZLATA LEGAL помогает заказчикам IT-разработки
ZLATA LEGAL помогает заказчикам защитить интересы при разработке сайтов, приложений, SaaS-сервисов, CRM, личных кабинетов, Telegram-ботов, маркетплейсов, платформ, интеграций и внутренних IT-систем.
Мы готовим и проверяем договоры с разработчиками, технические задания, приложения по этапам, условия оплаты, акты приемки, положения о передаче исключительных прав, лицензионные условия, NDA, поручения обработки персональных данных, правила передачи исходного кода, доступов и документации.
Анализируем риски проекта: кому будет принадлежать код, где находится репозиторий, на кого оформлен домен и хостинг, какие open source и сторонние компоненты используются, кто отвечает за интеграции, как принимаются работы, что делать при задержке, как сменить разработчика и как защитить данные заказчика.
Работаем с предпринимателями, IT-проектами и компаниями во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России.
Договор с IT-разработчиком должен защищать не только оплату и сроки. Он должен давать заказчику контроль над продуктом: кодом, правами, доступами, документацией, данными и возможностью развивать проект без зависимости от одного подрядчика.
Частые вопросы
Что главное в договоре с IT-разработчиком?
Главное — четко описать результат, ТЗ, этапы, оплату, приемку, передачу исходного кода, права на программу, доступы, документацию, сторонние компоненты, персональные данные и ответственность.
Нужно ли техническое задание?
Да. Без ТЗ сложно доказать, что именно должен был сделать разработчик. Для маленького сайта ТЗ может быть коротким, для приложения, SaaS, CRM или личного кабинета — детальным.
Кому принадлежат права на программу, созданную по заказу?
По общему правилу исключительное право на программу, созданную по заказу, принадлежит заказчику, если договором не предусмотрено иное. Но договор может изменить эту логику, поэтому раздел о правах нужно читать особенно внимательно.
Достаточно ли оплатить разработку, чтобы получить права?
Нет. Оплата сама по себе не решает все риски. В договоре нужно прямо закрепить переход прав, момент перехода, объем прав, передачу исходного кода и возможность доработки продукта другой командой.
Нужно ли передавать заказчику исходный код?
Если заказчик хочет контролировать продукт, да. Нужно прописать передачу исходного кода, репозитория, инструкций, документации, зависимостей и материалов, необходимых для поддержки и развития проекта.
На кого оформлять домен и хостинг?
На заказчика или его компанию. Если домен, хостинг, репозиторий и ключевые аккаунты оформлены на разработчика, заказчик зависит от него.
Можно ли вести разработку без договора, только по переписке?
Можно, но рискованно. Переписка может помочь как доказательство, но нормальный договор и ТЗ дают гораздо больше контроля над сроками, оплатой, правами и результатом.
Что делать, если разработчик использует open source?
Нужно попросить указать ключевые сторонние компоненты и гарантировать, что их использование не нарушает права третьих лиц и не ограничивает коммерческое использование продукта заказчиком.
Что делать, если разработчик привлекает других программистов?
В договоре нужно указать, что разработчик отвечает за субподрядчиков и гарантирует передачу прав на результаты, созданные всей командой.
Как принимать IT-работы?
Проверять результат по ТЗ, тестовым сценариям, интеграциям, доступам, коду, документации и критериям приемки. Замечания нужно фиксировать письменно до подписания акта.
Что такое гарантийный период?
Это срок после приемки, когда разработчик исправляет ошибки, связанные с выполненными работами. Новые функции и изменения обычно оплачиваются отдельно, если стороны не договорились иначе.
Что делать, если разработчик пропал?
Если код, репозиторий, домен, хостинг, база и доступы у заказчика, проект можно передать другой команде. Если все у разработчика, сначала придется добиваться передачи результата и доступов. Поэтому контроль нужно закладывать в договор до старта.
Нужно ли оформлять персональные данные с разработчиком?
Да, если разработчик получает доступ к базе пользователей, CRM, заявкам, личному кабинету, платежам, документам или логам. Нужен блок о поручении обработки персональных данных и безопасности.
Можно ли сделать договор с фрилансером?
Да, но нужно особенно внимательно прописать результат, оплату, передачу прав, исходный код, конфиденциальность, данные, акты и ответственность. С фрилансером риски доступа и прав часто выше, чем со студией.
Когда обращаться к юристу?
Лучше до оплаты аванса и старта разработки. На этой стадии можно нормально закрепить ТЗ, этапы, права, код, доступы и приемку, а не пытаться вернуть контроль над проектом после конфликта.
Связанные материалы