Поиск технического сооснователя после аутсорса разработки

Почему этот поиск усложняется после аутсорса

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

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

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

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

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

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

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

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

Начните с доступа и владения

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

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

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

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

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

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

Наведение порядка во владении даёт два эффекта. Оно снижает риски и показывает кандидатам, что вы имеете дело с неудобными фактами, а не прячете их.

Проверяйте качество кода простыми словами

Ни один серьёзный кандидат не ждёт идеального кода. Ему нужна честная картина.

Если продукт делало агентство или несколько фрилансеров, попросите одного опытного инженера посмотреть код день или два и написать короткую записку. Не мечтайте о переписывании. Задайте один практический вопрос: «Что может сломать нашу способность выкатывать обновления и поддерживать клиентов?»

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

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

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

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

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

Ищите особые доработки под конкретных клиентов

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

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

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

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

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

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

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

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

Проведите простой аудит за одну неделю

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

Дни 1–3

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

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

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

Дни 4–6

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

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

Шестой день используйте, чтобы превратить аудит в короткий бриф для кандидата. Уложитесь в несколько страниц. Включите текущую архитектуру, риски доступа, процесс релизов, клиентские обходные решения, главный техдолг и план исправлений на первые 90 дней. Сильные люди не ждут идеала. Они ждут честности.

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

Превратите аудит в бриф для кандидата

Грязный код редко отпугивает правильного человека. Неясная роль — отпугивает.

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

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

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

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

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

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

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

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

Простой пример стартапа

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

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

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

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

Теперь роль выглядела совсем иначе. Кандидат наследовал не просто MVP. Он наследовал MVP, скрытый рабочий процесс клиента и зависимость от агентства для деплоев и поддержки.

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

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

Ошибки, которые отталкивают сильных кандидатов

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

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

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

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

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

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

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

Быстрые проверки перед интервью

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

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

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

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

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

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

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

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

Когда вы можете объяснить всё это за десять минут, интервью становятся острее. Кандидаты перестают гадать и начинают думать о настоящей работе.

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

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

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

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

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

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

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