Подрядчик не передаёт исходники и доступы. Кто на самом деле владеет вашим IT-проектом? — 6 июля 2026 г. в 23:34:09.060
Подрядчик не передаёт исходники и доступы. Кто на самом деле владеет вашим IT-проектом? Один из самых неприятных моментов в IT-проекте наступает не тогда, когда подрядчик сорвал срок. Гораздо хуже, когда заказчик внезапно понимает: проект вроде бы “его”, деньги заплачены, сайт или сервис работает, но ключи от системы находятся у исполнителя. Доступы к серверу, домену, репозиторию, базе данных, дизайн-макетам, административной панели и интеграциям могут оказаться у подрядчика. Документации нет, исходный код не передан, аккаунты оформлены не на компанию, а акт уже подписан и счёт оплачен. Дальше начинается знакомая история: “мы вам всё передадим позже”, “это наша внутренняя разработка”, “вы платили за результат, а не за исходники”, “поддержка возможна только через нас”, “если хотите забрать проект — надо доплатить”. Для бизнеса это не техническая мелочь. Это вопрос контроля над активом. Если компания зависит от сайта, CRM, личного кабинета, приложения, внутренней системы, Telegram-бота, интеграций с 1С, Avito, маркетплейсами или платежами, отсутствие доступов превращает подрядчика в фактического владельца проекта. Формально бизнес может считать, что заказал разработку. Но на практике системой управляет тот, у кого есть сервер, домен, база данных, исходный код, репозиторий, админка, документация и возможность быстро заменить исполнителя. Если этого нет, заказчик не владеет проектом, а просто пользуется тем, что контролирует другой человек. Главная ошибка — обсуждать передачу доступов уже после конфликта. На старте всем кажется, что отношения хорошие, подрядчик адекватный, проект небольшой, “потом разберёмся”, “главное, чтобы работало”. Но если условия не прописаны заранее, потом спор становится неприятным. В договоре нужно прямо указать, что именно передаётся заказчику: исходный код, репозиторий, серверные доступы, домен, административные аккаунты, база данных, дизайн-макеты, техническая документация, инструкции, API-ключи и настройки интеграций. Не “сайт” и не “программный продукт” в общем виде, а конкретный перечень того, что должно оказаться у компании. Отдельно нужно определить момент передачи: после оплаты этапа, после подписания акта, после запуска, после завершения тестирования или в иной конкретный срок. Чем точнее это прописано, тем меньше пространства для фразы “передадим потом”. Ещё один важный вопрос — права на результат. В IT-проектах нужно различать возможность пользоваться сервисом и получение прав на код, дизайн, интерфейс, архитектуру, базу данных и другие результаты. Если права не переданы нормально, у заказчика может быть рабочий продукт, но слабая юридическая позиция при смене подрядчика, доработке системы или использовании кода в другом проекте. Также в договоре стоит заранее прописать ответственность за непередачу доступов и материалов: срок передачи, штраф, право удержать часть оплаты, обязанность передать результат даже при прекращении договора. Иначе исполнитель может затягивать передачу без реальных последствий. Отдельная зона риска — когда всё оформлено на подрядчика: домен, хостинг, облачные сервисы, платежные кабинеты, рекламные аккаунты, GitHub или GitLab. Это удобно в начале, но опасно в долгую. Правильная модель обратная: ключевые активы оформляются на заказчика, а подрядчику выдаются рабочие доступы. Если конфликт уже случился, сначала нужно спокойно собрать картину: что оплачено, какие акты подписаны, что обещал подрядчик, какие доступы уже есть, где находится код, на кого оформлены домен и сервер, есть ли переписка о передаче исходников и можно ли подтвердить, что они входили в объем работ. После этого можно выбирать стратегию: переговоры, претензия, требование передать результат, требование возместить убытки, расторжение договора или технический аудит с новым подрядчиком. Но чем меньше документов было на старте, тем дороже потом восстановление контроля.