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

Почему это быстро превращается в хаос

Запуск, сделанный агентством, часто работает нормально ровно до того дня, когда вам нужен контроль. И тут выясняется, что продукт уже в работе, но карта владения потеряна.

Обычно всё начинается со скорости. В неделю запуска люди выбирают самый быстрый вариант, а не самый аккуратный. Менеджер проекта из агентства открывает облачный аккаунт на рабочую почту, подрядчик создаёт рабочее пространство в аналитике, а кто-то покупает домен или плагин с любой удобной карты.

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

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

С DNS мелкая путаница легко превращается в реальный сбой. Я видел команды, которые знали, где размещён сам сайт, но не знали, кто управляет DNS-записями. Если никто не может войти в DNS-аккаунт, даже простое изменение — например, перенос почты или переключение трафика на новый сервер — может зависнуть на несколько дней.

Глубинная проблема в том, что доступ часто живёт в головах людей, а не в общем документе. Один разработчик знает сервер, другой — магазин приложений, а основатель уверен, что агентство оформило всё на компанию. Иногда так и есть. Но часто это только наполовину правда.

Именно поэтому дорожные карты и переписывание системы могут подождать. Если с владением неясно, любое изменение становится рискованным, и даже маленькая правка может превратиться в длинную неделю поиска паролей, счетов и согласований.

Что нужно контролировать в первую очередь

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

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

Обычно в первую очередь важны пять вещей:

• Оформите основную админ-учётку репозитория на свою компанию. Ваша команда должна контролировать доступ пользователей, правила веток, ключи деплоя и токены. Если у агентства остаётся верхний админ-доступ, у него по-прежнему главный переключатель.
• Заберите себе production-аккаунт в облаке или root-доступ. Используйте корпоративную почту, включите MFA и храните резервные коды там, где команда сможет их достать. Облачный аккаунт нельзя считать своим, если бывший подрядчик может первым сбросить доступ.
• Переведите домен и DNS под свой контроль. Если вы не владеете этими двумя вещами, вы не полностью управляете сайтом, почтой и будущими переносами.
• Получите права администратора во всех рабочих пространствах аналитики и выгрузите данные. Продуктовая аналитика, менеджеры тегов, дашборды и сырые выгрузки событий должны быть у вашей команды. Исторические данные легко потерять и очень трудно восстановить.
• Смените контакт для оплаты во всех платных сервисах. Облако, почта, инструменты поддержки, мониторинг, реклама и AI API должны выставлять счета напрямую вашей компании. Если списания всё ещё идут через агентство, вы не видите реальные операционные расходы.

Это не бумажная формальность. Это управление рисками. Если ваш продукт упадёт в воскресенье, команде нужно иметь возможность войти, оплатить счёт, обновить DNS, проверить аналитику и быстро выпустить исправление без чужого разрешения.

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

Начните с одного списка доступа

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

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

Достаточно простого набора колонок:

• Название инструмента или сервиса
• Для чего он используется
• Email владельца аккаунта
• У кого есть доступ администратора, редактора и просмотра
• Дата продления, карта оплаты и последний счёт

Email владельца важнее, чем многие основатели ожидают. Если аккаунт AWS, регистратор домена или аналитика оформлены на личный Gmail разработчика, вы пока не контролируете их по-настоящему. Ясно отметьте такие строки, чтобы команда могла заняться ими в первую очередь.

С правами доступа нужна конкретика. Формулировка «у агентства есть доступ» слишком расплывчата. Записывайте реальные имена и роли, потому что один админ может заблокировать всех остальных, а viewer почти ничего не может.

Данные по оплате подскажут, что может сломаться следующим. Добавьте даты продления, карту в системе и самый свежий счёт, который сможете найти. Так часто всплывают скрытые сервисы, о которых агентство забыло упомянуть, например CI runner, инструмент мониторинга или старый плагин, который до сих пор списывает деньги каждый месяц.

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

Защитите код и релизы

Ваш хостинг кода показывает, кто на самом деле владеет продуктом. Если агентство всё ещё контролирует верхний аккаунт в GitHub, GitLab или Bitbucket, ваша команда пока не управляет релизами.

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

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

Короткая проверка обычно помогает поймать самые рискованные места:

• корпоративный аккаунт владеет репозиторием или организацией
• ваша команда контролирует права на merge в main
• токены CI/CD и токены сборки видны вашим администраторам
• старые SSH-ключи и deploy-ключи удалены или заменены
• теги релизов совпадают с тем, что работает в production

Секреты требуют особого внимания, потому что они часто остаются спрятанными после передачи. Откройте настройки деплоя и проверьте переменные окружения, SSH-ключи, токены реестра пакетов, ключи подписи и любые секреты сборки, хранящиеся в pipeline. Если сотрудники агентства когда-либо имели доступ, замените их. Это займёт меньше времени, чем разбирать последствия нежелательного деплоя.

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

Сохраните чистую копию текущего production-релиза до любых изменений. Оставьте commit SHA, тег релиза, build artifact или образ контейнера и короткую заметку о том, какая версия конфигурации использовалась. Если следующий шаг сломает pipeline, у вас всё равно будет известная рабочая версия, к которой можно вернуться.

Переведите облако, домены и оплату на свою команду

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

Начните с облачного аккаунта. Переведите основного владельца и владельца оплаты на корпоративную почту, которой управляют основатели или внутренние сотрудники. Не оставляйте root-доступ привязанным к ящику агентства, фрилансера или бывшего сотрудника.

Потом проверьте домены и DNS. Ваша команда должна контролировать вход в аккаунт регистратора, DNS-записи, настройки продления и блокировку переноса. Если агентство держит DNS в отдельном сервисе, переведите и его тоже, иначе вам всё равно придётся обращаться к ним каждый раз, когда нужно изменить запись.

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

Безопасный порядок такой:

• Сначала добавьте владельцев и платёжные контакты вашей компании
• Затем переключите оплату на корпоративную карту
• Проверьте, что следующая оплата или продление пройдут успешно
• Скачайте последние счета и историю аккаунта
• Удаляйте старые карты только после того, как новая оплата заработала

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

Здесь помогает простое правило: сначала владение, потом уборка. Сначала возьмите контроль на свою компанию, проверьте, что оплата работает, сохраните историю биллинга и только потом убирайте агентство из аккаунта.

Проверьте аналитику, данные и поддержку

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

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

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

Проверьте права доступа особенно внимательно. Убедитесь, кто может:

• смотреть профили пользователей и историю заказов
• оформлять возвраты или кредиты
• просматривать тикеты и переписку в чате
• выгружать персональные данные
• менять роли администраторов или настройки безопасности

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

Доступ для восстановления не менее важен, чем повседневный доступ. Резервные коды, почты для восстановления, номера для SMS и приложения 2FA должны принадлежать вашей команде. Если восстановление аккаунта всё ещё идёт на телефон или ящик бывшего подрядчика, вы пока не контролируете эту систему.

Используйте такой порядок передачи

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

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

1. Сначала займитесь почтой, доменом и аккаунтами идентификации. Если агентство управляет вашим основным ящиком, DNS, Google Workspace, Microsoft 365 или single sign-on, оно часто может сбросить доступ почти ко всему остальному.
2. Затем заберите доступ к коду и деплою. Переведите исходный репозиторий, правила веток, CI/CD, доступ к магазину приложений, панели хостинга и учётные данные релизов на аккаунт своей команды.
3. После этого переведите облако и хранилища. Перенесите AWS, Google Cloud, серверы, buckets, базы данных, резервные копии и secret manager, когда ваша команда уже может выкладывать изменения и проверять их.
4. До следующего продления переключите владельцев оплаты. Способы оплаты, счета, налоговые данные и контакты по подпискам должны быть оформлены на вашу компанию, а не на агентство или фрилансера.
5. В конце попросите документы и проведите живой walkthrough. Письменные заметки полезны, но настоящий звонок по передаче обычно вскрывает мелочи, которые ломаются позже, например cron jobs, скрытые админ-пользователи или одноразовые скрипты.

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

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

Ошибки, которые тормозят передачу

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

Команды также создают проблемы, когда слишком рано отрезают агентство. Оставляйте доступ до тех пор, пока ваша команда не скопирует записи, не экспортирует настройки, не сохранит счета и не запишет, как работают релизы. Если удалить аккаунты слишком рано, можно потерять историю сборок, DNS-записи, ID рекламных аккаунтов или цепочки поддержки, которые объясняют старые проблемы клиентов.

Ещё одна медленная и болезненная ошибка — менять слишком много систем в один день. Основатель меняет оплату облака, обновляет секреты, переключает аналитику, обновляет pipeline релизов и меняет настройки домена до обеда. К вечеру вход перестаёт работать, и никто не понимает, какое изменение виновато. Меняйте по одной зоне за раз и проверяйте, что всё работает, прежде чем трогать следующее.

Инструменты поддержки и аккаунты магазинов приложений часто ускользают из виду. Стартап может вернуть доступ к GitHub и AWS, но всё равно пропускать срочные тикеты, потому что основной inbox принадлежит агентству. У мобильных команд та же проблема возникает, когда аккаунт Apple или Google всё ещё оформлен на подрядчика.

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

Короткая проверка должна включать:

• открытие production-репозитория с админ-доступом
• просмотр биллинга облака и активных подписок
• вход в аналитику и подтверждение живых данных
• отправку тестового ответа из inbox поддержки
• проверку того, кто может выпустить релиз в магазине приложений

Если ваша команда не может делать это сама, передача ещё не завершена.

Простой пример для стартапа

Лена управляет небольшой SaaS-компанией. Она заплатила агентству фиксированную сумму за запуск первой версии приложения, и оно вывело продукт в работу достаточно быстро, чтобы начать привлекать клиентов.

Через два месяца Лена хочет исправить просадку на регистрации и добавить одну новую функцию. Звучит просто — пока она не попросит доступ. Агентство всё ещё управляет облачным аккаунтом, настройками DNS и pipeline релизов. Если приложение упадёт, её команда даже не сможет перезапустить сервис без обращения к человеку вне компании.

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

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

Сначала она просит четыре вещи:

• админ-доступ к репозиторию кода и инструментам релиза
• перевод облака, DNS и оплаты на аккаунты, принадлежащие компании
• права администратора для аналитики, выгрузок и настроек событий
• контроль над inbox-ами поддержки, формами и ответами клиентам

Это решение почти сразу экономит ей время. Она находит старую DNS-запись, которую никто не задокументировал, платёжную карту, привязанную к владельцу агентства, и правило поддержки, которое тихо пересылало срочные тикеты на адрес, который никто не проверял.

Только после того, как команда Лены контролирует эти аккаунты, она планирует работу над продуктом. Неделю такой порядок может казаться медленным, но позже он предотвращает куда большую задержку. Разговор о дорожной карте мало что значит, когда ключи всё ещё у кого-то другого.

Быстрые проверки перед разговором о дорожной карте

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

Не полагайтесь на скриншоты и обещания. Откройте каждую систему, войдите и проверьте одно реальное действие вместе с командой.

Проверьте эти пять вещей, прежде чем обсуждать новую работу:

• Ваша команда может войти во все платные инструменты, которые поддерживают работу, измерение или обслуживание продукта.
• Ваша компания управляет основными email-аккаунтами, которые используются для админ-доступа, сброса паролей, счетов и уведомлений.
• Кто-то из вашей команды может выкатить изменение, откатить его и прочитать логи, не обращаясь к агентству за помощью.
• Вы видите данные об использовании продукта, выручке и истории поддержки в нужных инструментах.
• Все ежемесячные списания идут на корпоративную карту, корпоративный банковский счёт или платёжный профиль компании.

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

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

Если handover проверяет внешний CTO-советник, попросите не просмотр документов, а живую проверку. Десять минут реальных логинов, тестовый деплой и один аудит биллинга дадут больше, чем длинная встреча по дорожной карте.

Что делать дальше

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

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

Сделайте короткие заметки по нескольким вещам, которые команда будет использовать в первую очередь:

• как проходят релизы и кто может их одобрять
• где живёт оплата, кто платит и когда наступают продления
• как поступают запросы в поддержку и кто на них отвечает
• что делать, если ломается сайт, приложение или вход в систему

Эти заметки могут быть простыми и короткими. Одна страница с описанием релиза лучше, чем красивая wiki, которую никто не дописывает.

В то же время сократите доступ агентства до минимума, который ему ещё нужен. Если оно исправляет последний баг, оставьте доступ узким и ограниченным по времени. Уберите старые админские права, общие логины и доступ к оплате, который вашей команде больше не нужен. Здесь многие стартапы и ошибаются: им кажется, что передача закончена, а агентство всё ещё контролирует один аккаунт релиза, один логин домена или один inbox поддержки.

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

Если перед более крупными изменениями вам нужен второй взгляд, fractional CTO вроде Oleg Sotnikov может проверить пробелы в доступе, риски релизов, владение облаком и оплатой, а также следующие технические шаги. Такая проверка часто обходится намного дешевле, чем исправлять ещё одну ошибку передачи через месяц.