Как распределять долю технического сооснователя после MVP

Почему после MVP разделить доли становится сложно

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

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

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

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

Копированное деление скрывает эти различия. Основатели часто хватаются за привычную цифру вроде 50/50 или 60/40, потому что так кажется честнее и позволяет избежать неловкого разговора. На бумаге всё выглядит аккуратно. Через несколько месяцев это может ощущаться очень неуместно. Один основатель может вести переговоры с инвесторами и продавать. Другой может держать весь продукт на себе. Оба важны, но не всегда одинаково и не всегда в один и тот же момент.

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

Что именно вы делите сейчас

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

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

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

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

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

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

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

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

Оцените владение кодом и риск для продукта

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

Начните с простого вопроса: кто может выпустить исправление без помощи? Если только один основатель может проследить баг через backend, базу данных, auth, payments и настройку деплоя, этот человек несёт не только обязанности по программированию. Он держит на себе непрерывность работы.

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

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

Несколько прямых вопросов помогают разобраться:

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

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

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

Добавьте нагрузку на найм и команду

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

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

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

Считайте повторяющуюся командную нагрузку в реальных часах, а не в расплывчатом «участии». Смотрите на время на собеседования, follow-up, онбординг, code review, архитектурные обсуждения, помощь застрявшим разработчикам, подготовку релизов, правила тестирования и разбор багов. Эта работа повторяется каждую неделю, даже когда её никто не отмечает.

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

Настройка релизов тоже относится сюда. Кто-то должен отвечать за проверки качества, решать, что обязательно должно пройти перед выкладкой, смотреть на ошибки после релиза и следить, чтобы команда не выпускала избежимых проблем. То же самое касается инструментов и подрядчиков. CI, хостинг, мониторинг, source control, device lab, сервисы тестирования и учётные записи подрядчиков — у всего этого должен быть владелец. Если один основатель выбирает это, согласует и поддерживает работу, это тоже работа основателя.

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

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

Учитывайте привлечение инвестиций и работу основателя

После MVP работа основателя меняет форму. Один человек может по-прежнему писать код, а другой — неделями сидеть во встречах с инвесторами, переделывать deck, отправлять обновления, отвечать на follow-up и поддерживать медленные переговоры. Эта работа менее заметна, чем выпуск функций, но именно она двигает компанию вперёд.

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

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

Видимая работа и невидимая работа

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

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

Два основателя могут оба тратить по 15 часов в неделю вне основной продуктовой работы, но эффект может сильно отличаться. Один может проводить intro-звонки с инвесторами, которые никуда не ведут. Другой — проходить технический due diligence, замыкать цикл обратной связи от клиентов и удерживать раунд живым благодаря точному follow-up. Это не одно и то же.

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

Используйте простую систему оценки

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

Владение — это то, что каждый уже построил и всё ещё поддерживает. Нагрузка — это еженедельная работа, которая двигает компанию вперёд. Риск — это то, насколько человек уязвим, если всё пойдёт плохо, включая карьерные потери, репутацию и риск месяцами разбираться со сложными техническими проблемами. Привлечение инвестиций — это встречи с инвесторами, обновления, подготовка pitch deck и follow-up, который может занимать целые недели.

Сделайте шкалу простой. Оценивайте каждого основателя от 1 до 5 в каждой колонке. 1 означает ограниченный вклад в этой области. 3 — стабильный и заметный вклад. 5 — высокая ответственность с явным влиянием.

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

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

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

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

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

Два основателя заканчивают MVP и думают, что ответ очевиден. Основатель A должен получить намного большую долю, потому что A писал код. A построил продукт, держит продакшен и всё ещё получает ночные сообщения, когда что-то ломается. B не собирал стек, но ведёт продажи, проводит разговоры с клиентами и закрывает первые платные пилоты.

Именно здесь такие разговоры обычно идут не туда. Если смотреть только назад, A будет настаивать на 70/30. Если смотреть только на давление выручки, B будет тянуть почти к равному split. Оба упускают часть картины.

Они оценивают работу, которую делают сейчас, а не только ту, которая помогла выпустить MVP:

• Владение кодом и риск для продакшена: A 25, B 5
• Найм и нагрузка на команду: A 15, B 5
• Поиск клиентов и продажи пилотов: A 5, B 25
• Работа основателя вне ежедневной доставки, включая вопросы инвесторов: A 10, B 10

Итого у A получается 55 баллов, у B — 45. Split меняется от первого эмоционального черновика к более устойчивому варианту: 55/45 вместо 70/30.

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

Split 55/45 не означает, что спор закончен навсегда. Если B начнёт строить большую часть команды или A перестанет отвечать за продакшен, можно пересчитать всё заново. И обязательно использовать vesting, чтобы cap table не зафиксировал плохое предположение.

Суть простая: MVP важен, но работа после MVP важнее. Если текущая нагрузка близка, split тоже должен быть близким.

Ошибки, которые искажают split

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

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

Титулы тоже сбивают с толку. «CTO» звучит важно, и поэтому основатели иногда дают долю за ярлык, а не за работу. Это неверно. Доля должна следовать за тем, что человек реально несёт: продуктовые решения, владение кодом, найм, реакция на инциденты, компромиссы по roadmap и стоимость замены.

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

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

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

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

Обычно помогают три вещи:

• Оценивайте реальные обязанности, а не титулы.
• Учитывайте стоимость замены для знаний о системе.
• Прописывайте vesting и cliff до подписания.

Если цифры вызывают дискомфорт, это обычно значит, что вы наконец-то говорите о настоящей сделке.

Короткая проверка перед согласием

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

Перед тем как кто-то подпишет бумаги, задайте несколько прямых вопросов. Может ли каждый основатель объяснить цифру меньше чем за минуту? Соответствует ли split следующим 12–18 месяцам, а не только последним шести? Учли ли вы и прошлую, и будущую работу с обеих сторон? Будет ли сделка всё ещё честной после плохого квартала, сорванной выручки, неудачного найма и задержки продукта? И все ли понимают, что произойдёт, если кто-то уйдёт, перестанет участвовать или изменит роль?

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

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

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

Потом сравните заметки построчно. Не спорьте сначала о финальном проценте. Обсудите входные данные: кто владеет кодовой базой, кто несёт продуктовый риск, кто будет нанимать и кто проведёт месяцы в привлечение инвестиций или под давлением клиентов после MVP.

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

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

Сразу задайте правила, когда вы будете возвращаться к обсуждению. Не открывайте split каждый месяц, но пересматривайте его, когда работа действительно меняется. Хорошие триггеры — когда один из основателей переходит на full-time, компания нанимает инженерную команду или один человек надолго берёт на себя привлечение инвестиций.

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

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