Кому принадлежит сайт после разработки: код, домен, хостинг и доступы

Владение цифровым продуктом складывается из двух слоёв: технического (у кого доступы и на чьих аккаунтах живут активы) и юридического (кому по документам принадлежат права). Провал в любом из них делает владение фиктивным: с правами, но без доступов вы не можете управлять активом; с доступами, но без прав — не можете его защитить, продать или спокойно передать инвестору при проверке.

Типовая история выглядит буднично: «зарегистрируйте домен сами? да зачем, я всё сделаю» — и через два года бизнес с оборотом обнаруживает, что его адрес в интернете юридически принадлежит исполнителю, с которым давно расстались. Никакого злого умысла — просто так было быстрее на старте. Цена этой экономии выясняется в самый неудобный момент.

Проверьте прямо сегодня — на чьих аккаунтах живут эти четыре вещи:

• Домен: аккаунт у регистратора оформлен на вашу компанию или вас лично. Это самый болезненный актив: с доменом теряются адрес, почта и весь накопленный SEO. Восстановление через споры — долго и не гарантировано.
• Код: репозиторий (GitHub/GitLab) создан в вашем аккаунте или организации, подрядчик добавлен как участник. Не наоборот: «он даст архив, если что» — это не владение, а надежда.
• Сервер и хостинг: панель управления и биллинг хостера — на вашей почте и вашей карте. Продление хостинга не должно зависеть от чужой платёжной дисциплины.
• Сторонние сервисы: платёжный агрегатор, почта домена, аналитика, API-ключи интеграций — кабинеты на вас, у подрядчика — доступ сотрудника, который можно отозвать.

Юридический слой решается договором, и здесь важно не полагаться на «по умолчанию». Формулировки, которые должны присутствовать: исключительные права на созданный по договору код и материалы переходят заказчику; передача исходного кода — часть приёмки (в акте фиксируется, что и куда передано); подрядчик вправе использовать типовые библиотеки и наработки, но не может передавать ваш продукт третьим лицам.

Отдельно стоит проговорить открытые компоненты: почти любой современный продукт собран с использованием open-source библиотек, и это нормально — но их лицензии должны допускать коммерческое использование. Добросовестной студии эти пункты не мешают: они формализуют то, как она и так работает. Сопротивление передаче прав и исходников — ранний и очень честный сигнал о будущих проблемах.

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

• Доступ к репозиторию с актуальным кодом — и подтверждение, что задеплоенная версия собрана именно из него.
• Инструкция запуска и развёртывания: как поднять проект на новом сервере, если старый умрёт. Идеально — если это проверили при вас.
• Секреты отдельно от кода: пароли и ключи — в конфигурации окружения, а не зашиты в исходники; у вас — актуальный список, что где лежит.
• Схема инфраструктуры: какие серверы и сервисы задействованы, что от чего зависит, что и когда продлевать.
• Акт с передачей исключительных прав и перечнем переданного.
• Инструкция смены доступов: как отозвать доступ подрядчика и заменить ключи — на случай расставания.

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

Если же подрядчик уже недоступен или уклоняется — это сценарий спасения проекта: сбор того, что осталось, аудит состояния и восстановление контроля, о котором мы подробно писали в статье «Подрядчик бросил проект». Он тяжелее и дороже планового переноса — что возвращает к главному тезису: активы на заказчике с первого дня стоят дешевле любого «потом разберёмся».