Кому принадлежит ваш сайт

Вот вопрос, на который большинство владельцев бизнеса не могут ответить, не сделав звонок:

Если завтра ваш веб-разработчик перестанет отвечать, сможете ли вы изменить собственный сайт?

Не «будет ли это сложно». Сможете ли. Есть ли аккаунт, в который вы можете войти, место, где лежит код и до которого вы можете добраться, регистрация домена с вашим именем.

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

Владение — это не документ. Это список аккаунтов. Вот он.

Девять аккаунтов

Пройдитесь по ним применительно к своему сайту. Для каждого ответьте на два вопроса: чьи имя и почта указаны в аккаунте и можете ли вы войти в него прямо сейчас, ни у кого не спрашивая.

1. Домен

Самый важный пункт — и тот, где чаще всего что-то не так. Домен должен быть зарегистрирован на вашу компанию, у регистратора, где логин у вас, оплачен вашей картой и с включённым автопродлением.

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

2. DNS

Иногда у регистратора, иногда в другом месте, и это коммутатор: где размещён сайт, куда идёт почта, какие сервисы могут подтвердить, что они — это вы. Потерять доступ к DNS — значит не иметь возможности сменить хостинг и исправить доставку почты.

3. Хостинг

Сервер или платформа, на которой работает сайт. Ваш аккаунт, ваши счета. «Сайт на нашем сервере» — нормальная договорённость и вполне разумная услуга, но помните, что это услуга, которую вы арендуете, и выясните, как выглядит выход, до того как он понадобится.

4. Репозиторий кода

Собственно исходный код вашего сайта со всей историей изменений. Он должен лежать в вашей организации на GitHub или GitLab, а разработчик — быть приглашён туда участником, а не наоборот.

В этом разница между тем, чтобы нанять кого-то строить на вашей земле, и тем, чтобы жить в доме, который принадлежит ему. В обоих случаях можно быть вполне счастливым. Но только первый позволяет сменить строителя.

5. CMS или админ-панель

Место, где вы редактируете контент. У вас должен быть аккаунт администратора, а не аккаунт редактора, созданный для вас тем, кто оставил место администратора за собой.

6. Аналитика

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

7. Почта

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

8. Дизайн-файлы

Редактируемые исходники — файлы Figma, а не экспортированные картинки. Без них любое будущее изменение макета, цвета или иконки начинается с воссоздания того, за что вы уже заплатили.

9. Аккаунты в магазинах приложений и аккаунты разработчика

Если есть приложение, аккаунты разработчика Apple и Google должны быть вашими, а ключи подписи — переданы вам. Приложение, опубликованное с аккаунта агентства, — это приложение, которое вы не сможете обновить без него, и это самая чистая форма привязки, какая только бывает в софте. Подробнее об этом — в статье «Скорее всего, приложение вам не нужно».

Для магазина добавьте в список платёжный шлюз и мерчант-аккаунт — по той же причине.

Схемы привязки — и какие из них действительно злонамеренные

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

Случайная: агентство зарегистрировало домен, потому что так было быстрее. Встречается очень часто, почти никогда не бывает злонамеренной и элементарно исправляется переносом — если попросить, пока отношения не испортились.

Структурная: сайт на проприетарной платформе. Конструкторы сайтов, закрытые CMS, «наша собственная платформа». Работа существует, но уйти вместе с вами не может. Вас не держат в заложниках — вы просто купили то, что не переносится. Цена этого реальна и проявляется только тогда, когда вы пытаетесь переехать. См. статью «Против вашего конструктора сайтов».

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

Крайнюю версию этого мы встретили в WClinic — сети клиник в Санкт-Петербурге. У старого сайта вообще не было задокументированного способа деплоя: знание о том, как выкатить изменение, просто ушло вместе с тем, у кого оно было. Прежде чем браться за какие-либо функции, пришлось заново воссоздать окружение, контейнеризировать его и перенести в Git со сборочным пайплайном. Никто не сделал ничего плохого намеренно. И всё же компания не могла изменить собственный сайт.

Намеренная: доступ и есть продукт. Хостинг, цена которого устроена так, что уйти дороже, чем остаться, отказ передать исходный код, «код — наша интеллектуальная собственность». Это самый редкий вариант и единственный, который сигнализирует о проблеме с подрядчиком, а не с настройкой.

С последним пунктом важно точно понимать, о чём можно договариваться. Если студия повторно использует свои внутренние библиотеки в проектах разных клиентов — это нормально. Ваш сайт, ваш контент, ваши данные и ваша конфигурация — ваши. Если подрядчик не готов закрепить это письменно, это и есть ответ на ваш вопрос.

Аудит в виде таблицы, которую можно заполнить

Распечатайте её. Одна строка — один аккаунт. Не заполняйте по памяти — входите в каждый.

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

Как всё исправить без конфликта

Подавляющее большинство таких разговоров проходят легко, потому что другая сторона никогда и не собиралась вас привязывать. Сделайте из этого административный вопрос, а не противостояние.

Попросите письменно и назовите причину, не связанную с доверием. «Мы наводим порядок в аккаунтах компании для бухгалтера — можете перенести домен на наш аккаунт у регистратора и добавить нас владельцами в хостинг и аналитику?» С бухгалтерией никто не спорит.

Делайте всё по порядку важности. Сначала домен и DNS, потому что от них зависит всё. Затем репозиторий и хостинг. Потом аналитика, CMS, дизайн-файлы.

Не переносите домен в пятницу и не переносите его на той же неделе, что и хостинг. По одному изменению за раз, с проверкой почты после каждого.

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

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

Что обещаем мы

Это одна из пяти вещей, которые мы вынесли на страницу услуг как обещание, а не как функцию.

Всё принадлежит вам с первого дня. Исходный код — в вашей Git-организации. Редактируемые дизайн-файлы. Ваши облачные аккаунты, ваш домен, ваша аналитика. Мобильные сборки публикуются под вашими аккаунтами разработчика Apple и Google, а ключи подписи передаются вам.

Никакой привязки, никогда. После включённого периода поддержки обслуживание стоит $39 в месяц — или ничего. Забирайте код и уходите к другому подрядчику: он ваш в любом случае, без лицензий на продление и без платы за выход. Как мы пишем на сайте: остаться с нами — ваш ежемесячный выбор, а не зависимость, которую мы вам встроили.

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

Расскажите, что вам нужно. В ответ вы получите фиксированную цену и дату сдачи — бесплатно и без обязательств продолжать.

Частые вопросы

Домен зарегистрировал мой разработчик, и он годами прекрасно работает. Это срочно?

Не срочно, и это не оценка его работы. Это зависимость от одного человека в вопросе актива, через который проходит весь ваш бизнес. Перенесите домен, пока все довольны: перенос занимает двадцать минут и убирает риск, который никак не связан с чьими-то добрыми намерениями.

Это нормально, что сайт размещает агентство?

Да, и это может быть действительно выгодно. Ненормально — не видеть счёт, не иметь возможности получить копию сайта или платить за выход. Арендовать — нормально. Арендовать без возможности выйти — нет.

Может ли разработчик на законных основаниях оставить исходный код себе?

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

А если я потерял доступ, а разработчика уже нет?

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

Мы небольшая компания. Это правда стоит того, чтобы тратить на это полдня?

Скорее всего, это самые ценные полдня, которые вы можете потратить на эту тему. Всё остальное в вебе — о том, как получить больше от сайта, который у вас есть. А это — о том, чтобы он у вас продолжал быть.