Переход кода от агентства к стартапу: продолжайте выпускать продукт и верните контроль

Почему всё застревает

Большинство команд стопорится не только из-за кода. Их тормозит отсутствие контекста.

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

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

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

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

Проблемы повторяются снова и снова. Основатель может согласовывать работу, но не может сам выпустить её. Агентство знает систему, но почти ничего не пишет. Новая команда может читать код, но избегает billing, auth или инфраструктуры. Каждую неделю давление по roadmap побеждает уборку.

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

Разберите, чем вы владеете уже сейчас

Нельзя просить о чистой передаче, пока не ясно, что вообще существует. Многие основатели думают, что покупают только код, но агентство ещё и настраивало облако, домены, аналитику, доступ в app store, почту и скрипты для деплоя. Если хотя бы одна из этих вещей находится под неправильным логином, вы не контролируете продукт полностью.

Начните с карты активов

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

Минимально проверьте такие области:

• репозитории кода и package registries
• hosting, базы данных, storage и CI/CD инструменты
• домены, DNS, SSL и сервисы отправки email
• аналитика, отслеживание ошибок, support tools и платежи
• Apple App Store, Google Play и любые аккаунты вендоров, связанные с релизами

Основатели часто забывают про слой контроля. Репозиторий может быть в организационном аккаунте компании, но единственный admin-доступ всё ещё может быть у агентства. Счёт за облако может идти на вашу карту, но root-login всё ещё принадлежать агентству. Это разные проблемы, и обе важны.

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

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

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

Помогает простая маркировка red, yellow, green. Green — у вашей команды есть billing, admin-доступ и полезные заметки. Yellow — доступ частичный или не хватает документации. Red — систему всё ещё контролирует агентство или никто не понимает, как она работает. Эта карта покажет, что запрашивать первым, а что может подождать неделю.

Не останавливайте продуктовую работу во время перехода

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

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

Со стороны передачи сначала дайте видимость, а не контроль. Сначала предоставьте внутренней команде доступ на чтение: репозитории, hosting, логи, issue tracker, аналитику и историю deploy. Им нужно время, чтобы увидеть, как всё работает, прежде чем они начнут это менять. Уже одно это сильно снижает риск.

Двигайтесь маленькими, но синхронными шагами

Используйте короткий общий план, обычно на одну или две недели. Разместите в одном board и живые продуктовые задачи, и задачи по передаче, но чётко их пометьте. Всем должно быть видно, что нужно выпустить сейчас, а что может подождать пару дней.

Хорошо работает простое разделение:

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

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

Один основатель должен отвечать за решения, сроки и компромиссы во время перехода. Не вся leadership team. Не group chat. Один человек. Именно он решает, что выходит сейчас, что ждёт и когда агентство перестаёт трогать каждую часть продукта.

Если в стартапе нет сильного технического лидера внутри компании, part-time CTO может удержать процесс и не превратить его в больший проект, чем нужно. Задача простая: защитить delivery, снизить риск передачи и убедиться, что внутренняя команда учится системе, пока клиенты по-прежнему получают обновления.

Составьте практичный план передачи

Большинство передач ломается потому, что никто не забирает сначала скучные вещи. Прежде чем двигать хотя бы одну задачу, убедитесь, что компания владеет каждым admin-аккаунтом, который может заблокировать продуктовую работу: code hosting, cloud access, domains, DNS, email, analytics, app stores, monitoring и billing.

Сделайте свежие бэкапы, которые ваша команда сможет восстановить без агентства. Это значит исходный код, базы данных, конфигурации инфраструктуры, хранилище secrets и build artifacts. Если основатель не может ответить на вопрос «кто сможет восстановить production сегодня ночью?», значит, передача началась слишком рано.

Скопируйте всё до того, как что-то меняете. Синхронизируйте репозитории в аккаунт, который контролирует компания. Экспортируйте настройки production, переменные окружения, deployment configs, CI jobs и инвентарь серверов. Агентства часто помнят мелкие детали по привычке. Когда эти детали остаются только в чате или в памяти, они превращаются в outages.

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

1. Как команда выпускает релиз.
2. Как команда откатывает плохой релиз.
3. Кто получает первое уведомление, когда что-то ломается.
4. Кто может утвердить emergency change.
5. Что может подождать до рабочих часов.

Затем переводите владение по частям, а не всё сразу. Выберите один сервис, приложение или область функциональности с низким риском. Пусть внутренний lead возьмёт на себя планирование, code review и deployment для этой части, а агентство останется рядом, чтобы отвечать на вопросы. Если это хорошо проходит два или три релизных цикла, переходите к следующей части.

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

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

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

Соберите внутреннюю команду без лишнего найма

Большинству основателей не нужен целый engineering department, чтобы уйти от кода агентства. Сначала им нужен один понятный владелец. Этот человек должен понимать продукт, уверенно читать код, спокойно общаться с агентством и быстро принимать небольшие решения.

Если вы ещё не готовы нанимать full-time head of engineering, начните с senior lead или fractional CTO. Это хорошо работает, когда продукт всё ещё выходит каждую неделю, а бюджет ограничен. Один сильный владелец может убрать много лишних затрат ещё до того, как вы добавите новых людей.

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

Лёгкая стартовая команда часто выглядит так:

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

Что может подождать? Отдельная platform team, отдельная QA team и узкий специалист на каждый слой стека. Такие наймы имеют смысл позже, когда новый владелец увидит реальные узкие места.

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

Это особенно важно во время agency to in house handoff. Старый стек может выглядеть странно, но странный — не значит сломанный. Если он выпускается, держите его стабильным, пока у нового владельца не появится достаточно контекста, чтобы судить о нём трезво.

Контракторы всё ещё могут понадобиться на какое-то время. Держите их задачи узкими и ограниченными по срокам. Хорошие примеры — test coverage, cleanup deploy, документация или одна сложная миграция. Не давайте подрядчикам бесконечное продуктовое владение после того, как вы привели внутрь своего technical lead.

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

Как выглядит безопасный переход

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

В более безопасной версии перехода агентство не исчезает в первый день. Оно по-прежнему закрывает мелкие исправления, маленькие UI-баги и низкорисковые изменения, которые ему уже знакомы. Тем временем новый технический lead берёт на себя API, потому что именно эта область часто влияет на скорость продукта, качество данных и будущий найм.

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

Простой handoff на два спринта может выглядеть так:

• Спринт 1: агентство выпускает мелкие исправления и проводит нового lead через шаги deploy, логи и правила rollback.
• Спринт 2: новый lead выпускает API-работу, делает deploy и обрабатывает первые инциденты, пока агентство наблюдает.
• Конец спринта 2: внутренняя команда владеет deploy, alert’ами и incident response.
• Следующий месяц: агентство остаётся доступным только для редких edge cases или старого кода, который давно не трогали.

Это пересечение очень важно. Если агентство удерживает все production-знания до последнего дня, новая команда получает не владение, а стресс. Если внутренний lead берёт слишком много слишком рано, weekly releases начинают съезжать, и основатель теряет доверие к переходу.

Хороший handoff ощущается почти скучным. Демо по-прежнему проходят. Тикеты поддержки идут через одну очередь. Внутренний lead получает реальный контроль маленькими шагами, а не через огромный план переписывания.

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

Вопросы, которые рано показывают риск

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

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

Спросите, где хранятся secrets и аккаунты. Проверьте cloud access, DNS, логины в app store, платёжные инструменты, почтовые системы, фоновые задачи и API credentials. Основатели часто предполагают, что это всё принадлежит компании, а потом обнаруживают личные или агентские аккаунты уже в процессе.

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

Спросите, какие инструменты зависят от платных аккаунтов агентства. CI, аналитика, дизайн-файлы, feature flags, отслеживание ошибок, продление доменов и support tools — всё это может сидеть на чужом billing setup. Когда контракт меняется, доступ может исчезнуть быстрее, чем ожидает большинство основателей.

Спросите, какие сроки зависят от одного инженера агентства. Если запуск, миграция или отправка в store зависит от того, будет ли один человек свободен на этой неделе, план хрупкий.

Важно не только то, что вы отвечаете, но и как выглядит картина в целом. Если один и тот же человек контролирует deployments, production secrets и дату следующего релиза, это реальный риск. Если один и тот же аккаунт агентства владеет DNS, monitoring и app credentials, двигайте именно это первым.

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

Ошибки, которые усложняют переход

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

Ещё одна частая ошибка — переносить все системы в одну дату. Команды выбирают дедлайн, а потом пытаются одновременно поменять repos, hosting, DNS, analytics, billing и support tools. Одна скрытая зависимость может остановить весь поезд релизов. Поэтапный переход работает лучше. Сначала заберите под контроль доступ к коду, затем deployment, затем окружающие системы.

Слишком ранний найм тоже создаёт тормоза. Основатели иногда привлекают senior engineers ещё до того, как у них есть source control, cloud accounts, vendor logins, runbooks или даже понятная карта того, чем управляет агентство. В итоге эти люди занимаются дорогим детективным расследованием вместо разработки. Сначала соберите доступы и документацию. Потом нанимайте под реальные пробелы.

Команде также вредно откладывать скучную работу по безопасности. Если шаги rollback расплывчаты, тесты запускаются только на ноутбуках, а staging почти не похож на production, любая задача по передаче становится рискованнее. Перед переходом не нужно идеальное покрытие тестами, но нужен безопасный путь релиза. Даже простой чеклист для deploy, rollback и smoke test может спасти неделю паники.

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

Несколько ранних предупреждающих признаков:

• Никто не может назвать владельцев всех production-аккаунтов.
• Команда не может быстро восстановить последний стабильный релиз.
• Новые сотрудники в первый же день задают агентству базовые вопросы по настройке.
• Сроки продукта зависят от одного выходного для cutover.
• Юридические споры или споры по платежам начинают влиять на инженерные решения.

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

Короткие проверки и следующие шаги

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

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

• Компания контролирует billing, домены, репозитории, cloud accounts, аналитику, почту и доступ к app store.
• Backlog разделён на работу, которую нужно двигать сейчас, и работу, которая может подождать, пока владение станет чище.
• Один конкретный человек отвечает за incident calls во время перехода и знает, кто подключается, если production ломается.
• Внутренняя команда может безопасно выпустить одно небольшое исправление и откатить его при необходимости.
• Агентство отвечает на открытые вопросы письменно, с датами и владельцами.

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

Если вам на несколько недель нужен нейтральный технический владелец, Oleg Sotnikov на oleg.is делает именно такую fractional CTO работу: проверяет пробелы во владении, архитектуру, инфраструктуру и последовательность handoff, сохраняя стабильность delivery. Это может помочь, когда кодовая база кажется запутанной или отношения с агентством уже выдохлись, а команде нужен трезвый план вместо очередного спора о переписывании.

В ближайшие две недели держите scope небольшим. Перенесите все аккаунты и billing-отношения под контроль компании. Выберите одну безопасную задачу из backlog, которую внутренняя команда выпустит от начала до конца. Запишите, кто принимает решение во время инцидентов, релизов и эскалаций к агентству.

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

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