Один из самых неприятных IT-конфликтов для заказчика — когда подрядчик вроде бы сделал сайт, приложение, CRM, личный кабинет, Telegram-бот или онлайн-сервис, но не передает контроль над проектом.
Сайт работает, но домен оформлен на разработчика. Код есть, но лежит в его личном репозитории. Дизайн в Figma, но доступа у заказчика нет. Хостинг оплачен подрядчиком. Сервер настроен на его аккаунте. База данных закрыта. Админка есть, но только с ограниченными правами. Платежный агрегатор, аналитика, почта, API-ключи, App Store, Google Play, CRM и другие сервисы оформлены не на заказчика.
Пока отношения хорошие, это кажется технической мелочью. Но как только начинается спор по оплате, срокам, качеству или доработкам, доступы становятся рычагом давления.
Разработчик говорит: «Сначала оплатите всё, потом передам». Заказчик отвечает: «Сначала передайте код и доступы, потом оплатим остаток». Проект зависает. Бизнес не может сменить команду, проверить качество, исправить ошибки, перенести сайт, подключить нового подрядчика или доказать инвестору, что продукт принадлежит компании.
В такой ситуации важно действовать не эмоционально, а последовательно: зафиксировать, что именно не передано, проверить договор, собрать доказательства, направить письменное требование, отделить спор по оплате от обязанности передать оплаченные результаты, сохранить доступ к критическим активам и подготовить технический и юридический план возврата контроля.
ZLATA LEGAL помогает заказчикам IT-разработки во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России в спорах с разработчиками, веб-студиями, фрилансерами и IT-подрядчиками: по исходному коду, доступам, доменам, хостингу, дизайну, Figma-макетам, базам данных, правам на программу, приемке работ, оплате и расторжению договора.
Короткий ответ
Если подрядчик не передает исходники или доступы, сначала нужно не ругаться в чате, а собрать юридическую и техническую картину.
Нужно проверить договор, техническое задание, счета, акты, переписку, платежи, постановку задач и условия о правах. Затем составить перечень того, что должно быть передано: исходный код, репозиторий, домен, хостинг, сервер, база данных, админка, Figma, дизайн-макеты, документация, API-ключи, аккаунты внешних сервисов, платежный кабинет, аналитика, CRM, почта, магазины приложений и инструкции.
После этого подрядчику направляется письменное требование: передать конкретные материалы и доступы в конкретный срок, указать способ передачи, подтвердить отсутствие блокировок и передать права на результат в объеме договора. Если есть недостатки — их нужно зафиксировать отдельно, не подписывать пустой акт и не принимать работу без оговорок.
Если подрядчик продолжает удерживать проект, возможны переговоры, претензия, технический аудит, обращение к регистратору домена или хостингу, смена доступов, привлечение нового подрядчика, взыскание убытков, требование передать результат, расторжение договора или судебная защита.
Главная мысль: исходники и доступы — это не «приятный бонус» после разработки. Это часть контроля над цифровым продуктом. Если заказчик оплатил создание продукта и договор не оставляет контроль за подрядчиком, удержание кода и доступов может быть серьезным нарушением.
Что считается исходниками и доступами
Исходники — это не только один архив с кодом.
Для сайта или сервиса исходники могут включать backend, frontend, мобильное приложение, скрипты, конфигурации, миграции базы данных, тесты, инструкции по сборке, структуру проекта, зависимости, docker-файлы, CI/CD-настройки, документацию, API-описание, шаблоны писем, админку, дизайн-систему и материалы, необходимые для запуска и поддержки.
Доступы — это контроль над инфраструктурой: домен, DNS, хостинг, сервер, облако, репозиторий, база данных, админ-панель, CMS, Figma, CRM, аналитика, платежный агрегатор, почта, SMS-сервис, push-сервис, App Store, Google Play, Telegram-бот, API-ключи, CDN, SSL-сертификаты, резервные копии и внешние интеграции.
Если заказчик не имеет этих материалов, он может видеть работающий продукт, но не управлять им.
Почему разработчик не передает исходники
Причины бывают разные.
Иногда подрядчик действительно боится, что заказчик заберет код и не оплатит остаток. Иногда договор написан так, что исходный код не должен передаваться до полной оплаты. Иногда разработчик считает код своим, потому что использовал собственный движок или готовую платформу. Иногда проект собран на личных аккаунтах подрядчика, и передача требует технической миграции. Иногда подрядчик просто удерживает доступы как давление.
Бывает и хуже: кода в нормальном виде нет, документации нет, проект собран хаотично, часть работ делали субподрядчики, права не очищены, домен оформлен на фрилансера, а база лежит в чужом облаке.
Поэтому сначала нужно понять: это спор по оплате, спор по качеству, спор по правам, технический бардак или попытка удержать актив заказчика.
От этого зависит стратегия.
Первое действие: остановить хаос
В начале конфликта не стоит писать подрядчику эмоциональные сообщения, угрожать, менять все пароли без понимания, удалять аккаунты, ломать доступы или пытаться «забрать сервер силой».
Нужно зафиксировать текущее состояние.
Сделать скриншоты сайта, админки, переписки, задач, счетов, актов, платежей, репозитория, Figma, хостинга, домена, ошибок, уведомлений и отказов подрядчика. Сохранить договор, приложения, ТЗ, счета, акты, платежки, коммерческое предложение, переписку в мессенджерах, email, таск-трекере и CRM.
Если есть доступ к проекту, нужно аккуратно выгрузить то, что доступно законно: копии файлов, базу, настройки, список пользователей, дизайн, документы, логи, резервные копии. При этом нельзя выходить за пределы своих прав или взламывать чужие аккаунты.
Задача первого этапа — сохранить доказательства и не ухудшить позицию заказчика.
Проверить договор
Дальше нужно открыть договор и посмотреть несколько разделов.
Предмет договора: что именно должен был сделать подрядчик. Техническое задание: какие функции и материалы входили в проект. Этапы: что уже сдано и оплачено. Права: кому принадлежит код, дизайн, база и интерфейс. Исходники: обязан ли подрядчик передать исходный код. Доступы: кто должен владеть доменом, хостингом, репозиторием и аккаунтами. Приемка: подписаны ли акты и есть ли замечания. Оплата: есть ли долг и за какой этап. Расторжение: что передается при прекращении договора. Конфиденциальность и персональные данные: имел ли подрядчик доступ к базе пользователей.
Иногда заказчик уверен, что «код должен быть мой», а в договоре написано обратное: заказчик получает только право пользоваться сайтом, исходники не передаются, доработка только через исполнителя, домен и хостинг администрирует подрядчик. Это плохая, но не редкая ситуация.
Иногда наоборот: договор прямо говорит, что исходный код, права, доступы и документация передаются заказчику, но подрядчик просто не исполняет обязанность.
Если договора нет
Если договора нет, это не значит, что заказчик беззащитен.
Нужно собрать все, что подтверждает договоренности: переписку, счета, платежи, техническое задание, коммерческое предложение, презентации, сообщения в мессенджерах, задачи в трекере, макеты, доступы, демонстрации, акты, письма, записи созвонов при наличии законной записи, файлы и любые подтверждения, что подрядчик должен был создать конкретный результат.
Без договора спор сложнее, потому что условия придется доказывать по кускам. Но если есть оплата, переписка и фактическая работа, можно восстанавливать содержание договоренностей.
Особенно важны сообщения, где подрядчик обещает передать код, выдать доступы, оформить домен на заказчика, разместить проект на сервере заказчика или передать Figma.
Определить, что именно не передано
Нельзя писать подрядчику общую фразу: «Передайте все доступы».
Лучше составить конкретный реестр.
Например: исходный код backend и frontend; ссылка на репозиторий с административным доступом заказчика; инструкция по развертыванию; база данных и резервная копия; доступ к серверу; доступ к домену и DNS; доступ к хостингу; SSL-сертификаты; Figma-макеты; UI-kit; админка с полными правами; CRM; аналитика; платежный агрегатор; почта; API-ключи; Telegram-бот; документация; список сторонних компонентов; сведения о платных лицензиях; аккаунты App Store и Google Play.
Такое требование выглядит сильнее, потому что подрядчик не может ответить: «Что именно вы хотите?»
Кроме того, реестр помогает новой технической команде понять, что критично для продолжения проекта.
Проверить оплату
Спор по исходникам часто связан с оплатой.
Нужно честно определить, что оплачено, что не оплачено, какие этапы приняты, есть ли аванс, какие работы выполнены, какие работы спорные, есть ли задолженность и за что именно подрядчик требует деньги.
Если заказчик действительно не оплатил выполненный и подлежащий оплате этап, подрядчик будет использовать это как аргумент. Но это не всегда означает, что он вправе удерживать все активы проекта, особенно если часть результатов уже оплачена или договор предусматривает поэтапную передачу.
Если подрядчик требует оплату за работы с недостатками, нужно фиксировать недостатки и спорить по качеству, а не просто молчать.
Хорошая тактика — разделить: что заказчик готов оплатить после передачи конкретных материалов, что уже оплачено и должно быть передано безусловно, что является спорной доработкой, а что вообще не входило в ТЗ.
Проверить акты
Акты могут сильно влиять на позицию.
Если заказчик подписал акт без замечаний, подрядчик будет говорить, что работа принята, претензий нет, оплатите остаток. Если акт не подписан, подрядчик может говорить, что заказчик уклоняется от приемки.
Поэтому важно понять, какие акты подписаны, что в них написано, перечислены ли конкретные результаты, есть ли оговорки о недостатках, передавались ли права, код и доступы, была ли фактическая приемка через запуск проекта или оплату.
Если акт еще не подписан и есть проблемы, не нужно подписывать пустой акт «услуги оказаны» без перечня переданных результатов и замечаний. Лучше составить мотивированный отказ или акт с замечаниями: что работает, что не работает, что не передано, какие недостатки нужно устранить.
Не подписывать акт без передачи результата
Одна из главных ошибок заказчика — подписать акт, чтобы «не портить отношения», а потом пытаться получить исходники и доступы.
Если акт подписан без оговорок, подрядчик может утверждать, что все передал, заказчик все принял, а новые требования — это дополнительные работы.
Поэтому при приемке IT-проекта в акте или приложении к акту нужно перечислять результат: ссылка на репозиторий, версия кода, Figma, документация, доступы, сервер, домен, база, сборки, инструкции, сторонние компоненты и переход прав.
Если часть результата не передана, это нужно прямо указать. Например: «работы не принимаются в связи с непередачей исходного кода, доступа к репозиторию, резервной копии базы данных и административного доступа к домену».
Направить письменное требование
После анализа нужно направить подрядчику письменное требование.
Лучше не ограничиваться мессенджером. Требование можно направить по юридическому адресу, email из договора, через ЭДО, заказным письмом, по официальным каналам связи, указанным в договоре. Мессенджер можно использовать дополнительно, но не как единственный канал.
В требовании нужно указать договор, проект, оплаченные этапы, перечень непереданных материалов, срок передачи, способ передачи и последствия отказа.
Тон должен быть деловым. Не «вы украли наш сайт», а «требуем передать в срок до такой-то даты следующие результаты и доступы, предусмотренные договором и фактически созданные в рамках проекта».
Если есть долг, можно предложить встречный порядок: подрядчик передает результаты за оплаченные этапы немедленно, спорная часть оплачивается после устранения недостатков и передачи оставшихся материалов, либо стороны подписывают соглашение о передаче через акт.
Что требовать у подрядчика
В требовании можно просить передать исходный код, репозиторий, Figma-макеты, дизайн-систему, документацию, базу данных, резервные копии, доступы к серверу, домену, DNS, хостингу, админке, CMS, CRM, аналитике, платежным сервисам, почте, магазинам приложений, API, Telegram-боту и иным сервисам.
Также можно требовать подтвердить, что подрядчик не удерживает копии персональных данных сверх необходимого, не использует материалы заказчика для своих целей, не блокирует работу проекта, не передает данные третьим лицам и готов удалить или вернуть копии после завершения отношений.
Если проект содержит персональные данные, это отдельный важный блок: разработчик не должен сохранять дампы базы, доступы к CRM или пользовательские данные после окончания работ без законного основания.
Если подрядчик говорит «сначала оплатите»
Это типовая позиция.
Нужно смотреть договор и фактическую ситуацию. Если результат уже создан, этап оплачен, а договор предусматривает передачу после оплаты этапа, подрядчик должен передать материалы. Если оплата действительно не внесена за конкретный этап, можно обсуждать синхронную передачу: оплата против передачи кода и доступов.
Практический вариант — подписать соглашение о закрытии этапа: подрядчик передает код, доступы и права по перечню, заказчик оплачивает согласованную сумму, стороны фиксируют спорные и несогласованные работы отдельно.
Нельзя без анализа просто платить всю сумму в надежде, что после этого подрядчик станет добросовестным. Если он уже удерживает доступы, лучше платить только в привязке к конкретной передаче результата.
Если подрядчик говорит «код наш»
Нужно проверить договор.
Если предметом договора было создание программы, сайта, приложения, базы данных или иного результата по заказу, у заказчика может быть сильная позиция по переходу исключительных прав, если договор не предусматривает иное.
Но разработчик может ссылаться на то, что использовал свой движок, готовую платформу, библиотеку, шаблон или pre-existing code. Тогда нужно разделить: специально созданный результат для заказчика, готовые модули разработчика, open source, сторонние компоненты и материалы заказчика.
Заказчику важно получить не обязательно все внутренние универсальные инструменты подрядчика, а контроль над своим продуктом: право использовать, дорабатывать, поддерживать, переносить и развивать результат без зависимости от текущего разработчика.
Если разработчик заявляет «код наш», нужно требовать юридическое обоснование: на какой пункт договора он ссылается и какие именно части результата считает своими.
Если подрядчик не передает домен
Домен — критический актив.
Сначала нужно понять, на кого домен зарегистрирован: на заказчика, подрядчика, сотрудника, фрилансера, студию или неизвестное лицо. Это проверяется через регистратора и доступные сведения о домене.
Если домен зарегистрирован на заказчика, но доступ к личному кабинету у подрядчика, нужно восстанавливать доступ через регистратора. Если домен зарегистрирован на подрядчика, ситуация сложнее: нужно доказывать, что домен должен был быть оформлен или передан заказчику по договоренности.
В требовании к подрядчику нужно просить передать домен, доступ к регистратору, DNS-настройки, административный email и все сведения, необходимые для управления доменом.
На будущее домен всегда лучше оформлять сразу на заказчика или его компанию.
Если подрядчик не передает хостинг или сервер
С хостингом и сервером логика похожая.
Если аккаунт оформлен на заказчика, нужно восстановить доступ через хостинг-провайдера, сменить пароли и ограничить подрядчика. Если аккаунт оформлен на разработчика, нужно требовать перенос сайта, базы, файлов, настроек, резервных копий и конфигураций на аккаунт заказчика.
Важно не терять данные. Перед конфликтными действиями нужно сделать резервную копию сайта, базы, файлов, настроек и конфигурации сервера, если доступ есть.
Если подрядчик угрожает отключить сервер, нужно срочно готовить технический план миграции: копия сайта, база, DNS, почта, SSL, настройки, новая инфраструктура и новый подрядчик.
Если подрядчик не передает репозиторий
Репозиторий лучше всего переносить на аккаунт заказчика.
Если разработчик не передает GitHub, GitLab или Bitbucket, нужно требовать административный доступ или полный перенос репозитория с историей изменений, ветками, тегами, релизами и инструкцией по сборке.
Простой ZIP-архив может быть временным решением, но он хуже полноценного репозитория. В архиве может не быть истории, настроек, зависимостей, веток и актуального состояния.
Если подрядчик утверждает, что репозиторий содержит его собственные модули, нужно разделять спорные и бесспорные части. Но это не должно блокировать передачу того, что создано и оплачено для заказчика.
Если подрядчик не передает Figma и дизайн
Figma-макеты, UI-kit, дизайн-система, иконки, графика и прототипы — такие же активы проекта, как код.
Если дизайн оплачен, заказчик должен получить доступ к исходным макетам, а не только картинки или сверстанный сайт. Нужно требовать передачу проекта Figma в аккаунт заказчика или предоставление прав администратора, а также передачу исходных файлов и лицензий на шрифты, иконки, изображения и другие элементы.
Если макеты находятся в личном аккаунте дизайнера, это не должно становиться вечной зависимостью заказчика.
В требовании нужно прямо указать, что дизайн-макеты являются частью результата работ и должны быть переданы вместе с правами на использование и доработку.
Если подрядчик не передает базу данных
База данных — один из самых чувствительных активов.
В ней могут быть пользователи, заявки, клиенты, заказы, документы, платежные статусы, переписка, товары, справочники, настройки и бизнес-данные.
Нужно требовать резервную копию базы, структуру, схему, инструкции по восстановлению, описание таблиц, доступ к администрированию и подтверждение удаления лишних копий у подрядчика после передачи.
Если база содержит персональные данные, нужно отдельно контролировать безопасность передачи: защищенный канал, ограниченный доступ, пароль, журнал передачи, запрет на хранение копий и отзыв доступов.
Нельзя допускать, чтобы подрядчик удерживал базу пользователей как заложника в споре по оплате.
Если подрядчик не передает админку
Иногда заказчику дают доступ к админке, но не полный.
Например, можно редактировать тексты, но нельзя управлять пользователями, экспортировать базу, настраивать платежи, смотреть логи, подключать интеграции, менять роли, создавать администраторов или делать резервные копии.
Нужно проверить уровень прав. Если заказчик является владельцем продукта, у него должен быть полный административный доступ или отдельная модель управления, прописанная в договоре.
В требовании нужно указать не просто «дать доступ», а «предоставить административный доступ с правами владельца/суперадминистратора, позволяющий управлять пользователями, настройками, интеграциями, экспортом данных и резервными копиями».
Если подрядчик не передает аккаунты внешних сервисов
IT-проект почти всегда зависит от внешних сервисов.
Платежный агрегатор, почта, SMS, push-уведомления, аналитика, CRM, карты, CDN, облако, API, магазины приложений, Telegram-бот, WhatsApp Business, доменная почта, сервисы рассылки и виджеты могут быть оформлены на подрядчика.
Нужно составить полный список таких сервисов и понять, какие из них критичны. Затем требовать передачу владельческих прав или миграцию на аккаунты заказчика.
Если сервис нельзя передать технически, подрядчик должен помочь мигрировать настройки, ключи, шаблоны, данные и интеграции.
На будущее все ключевые аккаунты должны создаваться на стороне заказчика, а подрядчик должен получать доступ как исполнитель.
Технический аудит
При конфликте полезно привлечь независимого технического специалиста.
Он может проверить, что реально работает, где лежит код, есть ли доступы, можно ли перенести проект, какие компоненты используются, есть ли критические ошибки, есть ли зависимость от подрядчика, какие материалы нужны для восстановления контроля и сколько стоит доработка другой командой.
Технический аудит помогает перевести спор из эмоций в факты.
Например: не передан репозиторий, отсутствует инструкция по сборке, база лежит на сервере подрядчика, домен оформлен на третье лицо, Figma недоступна, платежные ключи на аккаунте разработчика, документации нет, код без тестов, open source лицензии не раскрыты.
Такой отчет можно использовать в переговорах, претензии и при подготовке судебной позиции.
Претензия подрядчику
Если обычное требование не помогло, готовится претензия.
В претензии нужно описать договор, факты оплаты, выполненные и невыполненные обязательства, непереданные материалы, нарушение сроков или качества, последствия для бизнеса, требования заказчика и срок исполнения.
Требования могут быть разными: передать исходный код, доступы, домен, хостинг, базу, Figma, документацию; устранить недостатки; подписать акт передачи; вернуть аванс; возместить убытки; прекратить неправомерное использование данных; подтвердить удаление копий; расторгнуть договор и передать оплаченные результаты.
Претензия должна быть конкретной. Чем точнее перечень требований, тем сложнее подрядчику уходить от ответа.
Переговорное решение
Не каждый спор нужно сразу вести в суд.
Иногда лучше быстро вернуть контроль над проектом через соглашение.
Например, стороны подписывают соглашение: подрядчик передает код, репозиторий, домен, хостинг, базу, Figma и документацию по перечню; заказчик оплачивает согласованную сумму; спорные доработки исключаются; стороны фиксируют переход прав; подрядчик удаляет копии персональных данных; доступы подрядчика прекращаются после передачи.
Такое соглашение может быть дешевле и быстрее суда.
Но платить по нему нужно только под конкретную передачу. Не «переведите деньги, потом все дадим», а синхронно: акт, доступы, проверка, оплата, подтверждение.
Когда нужен суд
Суд нужен, если подрядчик удерживает проект, отказывается передавать результат, не возвращает оплату, нарушает права, не передает домен или код, скрывает результат, использует материалы заказчика или причинил существенные убытки.
В суде можно заявлять требования в зависимости от ситуации: обязать передать результат и доступы, взыскать убытки, вернуть аванс, взыскать неустойку, признать права, запретить использование материалов, расторгнуть договор, взыскать стоимость устранения недостатков или восстановления проекта.
Но суд — не первая магическая кнопка. К нему нужно готовить доказательства: договор, ТЗ, оплату, переписку, акты, требования, техническое заключение, скриншоты, отказ подрядчика, оценку убытков и связь между нарушением и потерями заказчика.
Убытки
Если из-за удержания доступов бизнес потерял деньги, это может быть вопросом убытков.
Например, сайт отключили, реклама остановилась, пользователи не могли оплатить, сервис не работал, заказчик вынужден был срочно нанимать новую команду, восстанавливать проект, переносить сервер, заново делать дизайн или оплачивать экстренную миграцию.
Но убытки нужно доказывать. Нельзя просто написать «мы потеряли миллион». Нужно показать документы, платежи, отчеты, падение продаж, счета нового подрядчика, техническое заключение, связь с действиями разработчика и разумность расходов.
Поэтому с самого начала конфликта нужно фиксировать последствия: простои, ошибки, потери заявок, отключение сервисов, переписку с клиентами, расходы на восстановление.
Персональные данные
Если у подрядчика есть доступ к базе пользователей, возникает отдельный риск по персональным данным.
Разработчик может иметь дампы базы, доступ к CRM, серверу, логам, заявкам, платежным данным, документам, переписке и личному кабинету.
Нужно требовать не только передачу доступа, но и прекращение обработки данных, возврат или удаление копий, отзыв доступов, подтверждение удаления и информацию о том, были ли данные переданы субподрядчикам.
Если есть риск утечки, нужно отдельно оценивать действия оператора: внутреннее расследование, ограничение доступа, смена паролей, проверка логов, уведомления и меры безопасности.
В договоре с разработчиком на будущее обязательно нужен блок о поручении обработки персональных данных.
Что делать с паролями и ключами
После возврата контроля нужно срочно провести ревизию доступов.
Сменить пароли, отключить аккаунты подрядчика, заменить API-ключи, проверить SSH-доступы, токены, ключи платежных сервисов, доступы к CRM, почте, аналитике, домену, хостингу, Git, Figma, ботам, облакам и магазинам приложений.
Также нужно проверить, не остались ли у подрядчика скрытые админ-аккаунты, ключи деплоя, доступы к базе, резервные копии или webhook-интеграции.
Это уже не только юридический, но и технический вопрос безопасности.
Не ломать чужие аккаунты
Даже если подрядчик ведет себя плохо, заказчику не стоит пытаться взломать аккаунт, обойти защиту, использовать чужие пароли, заходить в личные кабинеты подрядчика без права или удалять его материалы.
Это может ухудшить позицию заказчика.
Правильная линия — требовать передачу того, что принадлежит заказчику или должно быть передано по договору, восстанавливать доступы через официальные каналы, фиксировать нарушения, использовать претензию и правовые механизмы.
Эмоциональное «забрать любой ценой» может превратить заказчика из пострадавшей стороны в участника нового конфликта.
Если проект нужно срочно спасать
Иногда ждать нельзя: сайт упал, домен скоро истекает, сервер отключают, реклама идет, пользователи платят, база под угрозой.
Тогда параллельно с юридической претензией нужно запускать технический план спасения.
Что можно сделать: восстановить доступ к домену через регистратора, поднять резервную копию, перенести сайт на новый хостинг, сменить DNS, отключить старые ключи, сделать экспорт базы, подключить нового подрядчика, временно закрыть оплату, предупредить пользователей о технических работах, сохранить доказательства простоя.
Но каждый шаг нужно делать аккуратно, чтобы не нарушить права третьих лиц и не потерять доказательства.
Если подрядчик пропал
Если разработчик просто исчез, стратегия зависит от того, что есть у заказчика.
Если домен, хостинг, репозиторий, Figma и база у заказчика, нужно менять доступы, делать аудит и передавать проект другой команде.
Если все у разработчика, нужно направлять требования по всем известным каналам, фиксировать отсутствие ответа, восстанавливать домен и аккаунты через провайдеров, искать резервные копии, собирать переписку и оценивать судебные требования.
Если разработчик — физическое лицо или самозанятый, важно иметь его реальные данные. Если их нет, уже на этапе договора была допущена ошибка. На будущее всегда нужно проверять контрагента до оплаты.
Если подрядчик — веб-студия
Со студией обычно больше шансов на договорную работу, но и больше сложностей с субподрядчиками.
Студия может говорить, что дизайн делал внешний дизайнер, backend — один фрилансер, frontend — другой, а доступы у DevOps. Для заказчика это не должно быть проблемой, если договор заключен со студией и она отвечает за команду.
В требовании нужно обращаться к договорному исполнителю. Он должен собрать результат у своих людей и передать заказчику.
Если студия не получила права от своих субподрядчиков, это ее внутренний риск, если договор с заказчиком предусматривает передачу прав.
Если подрядчик — фрилансер
С фрилансером риск часто выше: все завязано на одном человеке, личных аккаунтах, мессенджерах и устных договоренностях.
Нужно особенно внимательно собирать переписку, платежи, договоренности, скриншоты аккаунтов и подтверждения, что проект создавался по заказу.
Если фрилансер не передает доступы, важно быстро понять, какие активы можно восстановить через официальных провайдеров, а какие придется требовать через претензию и суд.
На будущее с фрилансером нужно заключать короткий, но конкретный договор: результат, сроки, оплата, права, исходники, доступы, Figma, домен, хостинг, персональные данные и порядок расторжения.
Если разработчик использовал свой движок
Иногда подрядчик говорит: «Мы не передаем код, потому что сайт сделан на нашем движке».
Это может быть нормальной моделью, если заказчик заранее покупал не индивидуальную разработку, а право пользоваться платформой подрядчика. Тогда нужно смотреть договор: что заказчик приобрел, можно ли перенести сайт, как выгрузить данные, что будет при прекращении договора и кто владеет результатом.
Но если заказчик платил именно за разработку собственного продукта, а про закрытый движок в договоре не было ясного условия, позиция подрядчика может быть спорной.
В такой ситуации нужно разделить: собственный движок подрядчика, индивидуальные доработки заказчика, дизайн, контент, база, настройки, домен и данные. Даже если движок остается у подрядчика, заказчик может требовать свои материалы, данные и права на индивидуально созданные элементы.
Если проект на Tilda, WordPress, Битрикс или no-code
Для конструкторов и CMS важно понимать, что передается не всегда «исходный код» в классическом смысле.
Если сайт на Tilda, Webflow, WordPress, Битрикс, Bubble, Retool, Airtable, Notion, Make или другой платформе, заказчику нужно получить аккаунт, административные права, настройки, шаблоны, контент, домен, интеграции, базу, платежи, аналитику и инструкции.
Если аккаунт платформы оформлен на подрядчика, нужно требовать передачу проекта или миграцию на аккаунт заказчика.
В договоре на такие проекты нужно честно писать, что создается: собственная разработка, настройка CMS, сайт на конструкторе, low-code-приложение или конфигурация готовой платформы.
Если доступы оформлены на сотрудника заказчика
Иногда проблема не в подрядчике, а в бывшем сотруднике заказчика.
Домен, хостинг, GitHub, Figma, CRM, рекламный кабинет или платежный сервис могли быть оформлены на личную почту менеджера или разработчика внутри компании. После увольнения доступ потерян.
Здесь логика похожая: восстанавливать через провайдеров, собирать документы о принадлежности проекта компании, проверять корпоративную почту, платежи, договоры и внутренние распоряжения.
На будущее ключевые IT-активы должны оформляться на компанию, а не на личные аккаунты сотрудников.
Как предотвратить удержание исходников
Лучший способ решить проблему — не допустить ее.
До старта разработки нужно прописать в договоре: код ведется в репозитории заказчика, домен и хостинг оформляются на заказчика, Figma передается после этапа дизайна, исходники передаются по этапам, права переходят после оплаты соответствующего этапа, доступы выдаются заказчику с правами администратора, документация входит в результат, подрядчик не вправе удерживать оплаченные материалы, а при расторжении передает все фактически созданное и оплаченное.
Также нужно платить по этапам, не переводить весь бюджет вперед, не принимать работу без кода и доступов, не подписывать пустые акты, вести задачи в трекере и хранить всю переписку.
Что должно быть в договоре на будущее
В договоре с IT-подрядчиком нужно прямо указать, что результат включает исходный код, репозиторий, дизайн-макеты, Figma, UI-kit, базу данных, документацию, инструкции, доступы, домен, хостинг, сервер, админку, интеграции, ключи и иные материалы, необходимые для самостоятельного использования и развития проекта.
Также нужно указать момент передачи: по этапам или после оплаты конкретного результата. Обязанность передать права: исключительные права на специально созданные результаты переходят заказчику. Право доработки: заказчик может привлекать третьих лиц. Open source: подрядчик раскрывает важные сторонние компоненты. Персональные данные: подрядчик обрабатывает их только по поручению заказчика. Расторжение: оплаченные результаты передаются заказчику в любом случае.
Такие условия не гарантируют отсутствие конфликта, но сильно повышают позицию заказчика.
Частые ошибки заказчика
Первая ошибка — весь проект оформлен на аккаунтах подрядчика. Вторая — нет договора или ТЗ. Третья — нет условия о передаче исходников. Четвертая — репозиторий не на стороне заказчика. Пятая — Figma и дизайн остались у подрядчика. Шестая — домен оформлен на разработчика. Седьмая — подписан акт без передачи кода и доступов. Восьмая — оплата не привязана к этапам. Девятая — подрядчику дали реальные персональные данные без условий обработки. Десятая — нет резервных копий и документации.
Все эти ошибки обычно выглядят мелкими до первого конфликта. Потом именно они решают, сможет ли заказчик быстро вернуть контроль над проектом.
Что делать пошагово
Сначала зафиксировать ситуацию: что работает, что не передано, какие доступы есть, какие отсутствуют, что оплачено, какие акты подписаны, какие обещания есть в переписке.
Затем проверить договор, ТЗ, счета, акты, платежи и условия о правах. После этого составить реестр непереданных материалов и доступов. Затем направить письменное требование подрядчику с конкретным сроком и перечнем.
Параллельно провести технический аудит и понять, можно ли спасти проект без подрядчика: восстановить домен, перенести хостинг, выгрузить базу, получить копию сайта, сменить пароли, подключить нового специалиста.
Если подрядчик готов договариваться, оформить соглашение о передаче и закрытии расчетов. Если нет — готовить претензию, фиксировать убытки и выбирать способ защиты: взыскание, расторжение, требование передачи результата, запрет использования материалов или судебный спор.
Локальный аспект: Владивосток, Приморье и Дальний Восток
Во Владивостоке и Приморском крае бизнес часто заказывает прикладные IT-решения под реальные процессы: сайты, CRM, личные кабинеты, сервисы для логистики, ВЭД, поставок из Китая, складов, морской отрасли, Telegram-боты, B2B-платформы и внутренние панели учета.
Такие проекты могут начинаться быстро: знакомый разработчик, небольшая студия, договор «потом», доступы на личной почте, задачи в мессенджере. Пока все идет нормально, это удобно. Но если подрядчик исчезает или конфликтует, бизнес может потерять не просто сайт, а часть операционного процесса: заявки, клиентов, документы, статусы, платежи и данные.
Для регионального бизнеса особенно важно оформлять контроль над IT-активами заранее. Домен, хостинг, код, Figma, база, CRM, платежи и аналитика должны принадлежать заказчику или быть переданы ему по понятной процедуре.
Как ZLATA LEGAL помогает, если подрядчик не передает исходники или доступы
ZLATA LEGAL помогает заказчикам в спорах с IT-разработчиками, веб-студиями, фрилансерами и подрядчиками, которые не передают исходный код, доступы, домены, хостинг, репозиторий, Figma-макеты, базу данных, админку, документацию или права на результат.
Мы анализируем договор, техническое задание, счета, акты, переписку, платежи, постановку задач, условия о правах, приемку и фактическое состояние проекта. Готовим требования о передаче исходников и доступов, претензии, соглашения о закрытии проекта, акты передачи, условия о переходе прав, документы по персональным данным и позицию для переговоров или суда.
Работаем совместно с техническими специалистами, если нужно зафиксировать, что именно не передано, какие доступы отсутствуют, можно ли перенести проект, какие ошибки есть в коде, как сохранить базу и что потребуется новой команде.
Помогаем проектам во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России вернуть контроль над цифровыми активами и выстроить договорную модель так, чтобы в будущем подрядчик не мог удерживать бизнес за исходники и доступы.
Подрядчик не должен превращать код, домен, хостинг или Figma в заложников спора. Если проект создавался для заказчика, контроль над ним нужно возвращать через документы, доказательства, техническую фиксацию и понятную правовую позицию.
Частые вопросы
Что делать, если разработчик не передает исходный код?
Проверить договор, оплату, акты и условия о правах. Затем направить письменное требование с перечнем исходников, репозитория, документации и сроком передачи. Если отказ продолжается — готовить претензию, технический аудит и правовую позицию.
Можно ли требовать исходники, если сайт уже работает?
Да, если исходный код должен был быть передан по договору или является частью результата разработки. Работающий сайт без исходников не дает заказчику полноценного контроля над продуктом.
Что делать, если разработчик говорит, что код принадлежит ему?
Нужно проверить договор. Если программа или сайт создавались по заказу, у заказчика может быть сильная позиция, если договор не предусматривает иное. Но нужно отдельно оценить готовые модули, open source, платформу разработчика и специально созданный код.
Можно ли не платить остаток, пока не переданы доступы?
Зависит от договора и фактической ситуации. Часто безопаснее предложить синхронную модель: передача конкретных материалов и доступов против оплаты согласованной суммы. Не стоит платить весь остаток без фиксации передачи.
Что делать, если домен оформлен на разработчика?
Требовать передачу домена и доступа к регистратору. Если есть договоренности, что домен создавался для заказчика, их нужно доказывать договором, оплатой и перепиской. На будущее домен нужно оформлять сразу на заказчика.
Что делать, если хостинг на аккаунте подрядчика?
Требовать перенос сайта, базы, файлов, настроек и резервных копий на аккаунт заказчика. Если есть риск отключения, нужно срочно готовить техническую миграцию.
Что делать, если не передают Figma-макеты?
Требовать передачу исходных макетов, UI-kit, компонентов, графики и прав на дизайн, если дизайн был частью оплаченного результата. Картинки или скриншоты не заменяют исходные макеты.
Можно ли подписывать акт без исходников?
Рискованно. Если исходники, доступы и документация должны быть частью результата, их нужно указать в акте. Если они не переданы, акт лучше не подписывать без оговорок.
Что делать, если разработчик пропал?
Собрать доказательства, восстановить доступы через провайдеров, проверить домен, хостинг, репозиторий, Figma, базу, платежи и CRM, привлечь технического специалиста и готовить письменные требования или судебную защиту.
Что делать, если проект на конструкторе?
Требовать передачу аккаунта, проекта, домена, настроек, контента, интеграций, базы и инструкций. Для конструктора исходный код может не передаваться в классическом виде, но контроль над проектом должен быть у заказчика.
Можно ли забрать сайт с сервера подрядчика самостоятельно?
Только если у заказчика есть законный доступ и право на соответствующие материалы. Взлом, обход защиты или вход в чужие аккаунты без права может ухудшить позицию заказчика.
Нужен ли технический аудит?
Да, если спор серьезный. Технический специалист поможет зафиксировать, что не передано, какие есть ошибки, где лежат данные, можно ли перенести проект и сколько будет стоить восстановление.
Можно ли взыскать убытки с разработчика?
Можно, если доказать нарушение, размер убытков и связь между ними. Например, простой сайта, расходы на восстановление, перенос, доработку, потерю заявок или оплату новой команды.
Что делать с персональными данными у подрядчика?
Потребовать прекратить обработку, вернуть или удалить копии, отозвать доступы, подтвердить удаление и сообщить о субподрядчиках. Если есть риск утечки, нужно отдельно оценивать меры реагирования.
Как предотвратить такой конфликт?
Сразу оформлять договор с ТЗ, передачей исходников по этапам, репозиторием на стороне заказчика, доменом и хостингом на заказчика, актами с перечнем результатов, правами на код и дизайн, документацией и порядком передачи доступов.
Связанные материалы