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

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

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

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

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

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

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

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

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

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

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