Бизнес и цифровые активы

Развод IT-предпринимателя, стартапера или владельца SaaS-проекта

Развод IT-предпринимателя, стартапера или владельца SaaS-проекта — один из самых сложных и недооценённых видов имущественного спора.

В обычном бизнесе хотя бы понятно, что искать:

недвижимость;
склад;
товар;
автомобили;
оборудование;
расчётные счета;
доли в ООО;
договоры с клиентами.

В IT-бизнесе главная ценность может быть вообще не видна снаружи.

Она может находиться в:

коде;
репозиториях;
доменах;
GitHub, GitLab или Bitbucket;
облачной инфраструктуре;
аккаунтах App Store, Google Play, Stripe, Paddle, AWS, Google Cloud, Azure;
базе пользователей;
подписках;
MRR и ARR;
интеллектуальных правах;
договорах с разработчиками;
правах на дизайн, интерфейс, базу данных и контент;
долях в иностранной компании;
опционах;
инвестиционных документах;
SAFE, convertible note или аналогичных инструментах;
будущей оценке проекта;
валютной выручке;
команде, которая работает удалённо;
доступах к аналитике, рекламе, CRM, платежам и инфраструктуре.

На бумаге у супругов может не быть почти ничего.

Нет офиса.

Нет станков.

Нет склада.

Нет автомобилей.

В ЕГРЮЛ может быть пустая компания с уставным капиталом 10 000 рублей.

Но фактически есть SaaS-продукт, который приносит валютную выручку, имеет клиентов, репозиторий, домен, команду, инвестора и перспективу оценки в миллионы долларов.

Или наоборот: супруг говорит, что проект «почти единорог», но на деле это прототип без прав на код, без выручки, без инвестиций и с командой фрилансеров, которым не передали исключительные права.

Поэтому IT-бизнес при разводе нельзя делить по ощущениям.

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

ZLATA LEGAL сопровождает семейные и имущественные споры, где развод связан с бизнесом, IT-проектами, SaaS, иностранными компаниями, интеллектуальными правами, валютными доходами, долями, опционами, инвестициями и компенсациями.

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

Короткий ответ

При разводе IT-предпринимателя или владельца SaaS-проекта нужно анализировать не только долю в российском ООО.

Важно понять весь цифровой и корпоративный контур:

кто основал проект;
когда проект появился;
на кого оформлена компания;
есть ли иностранная компания;
кому принадлежат доли;
есть ли опционы или vesting;
кто владеет кодом;
где репозитории;
кто имеет доступ к GitHub, GitLab, серверам и облакам;
кому принадлежит домен;
на кого зарегистрированы аккаунты;
кто получает платежи от клиентов;
есть ли MRR, ARR, подписки или разовые продажи;
есть ли валютная выручка;
есть ли инвесторы;
подписывались ли SAFE, convertible note, SHA, SAFE-like или иные инвестиционные документы;
есть ли права на дизайн, базу данных, контент и бренд;
есть ли договоры с разработчиками;
переданы ли исключительные права на код;
есть ли open source-риски;
работает ли удалённая команда;
не выводится ли продукт на новую компанию;
не меняются ли доступы перед разводом;
не переводятся ли клиенты, платежи и домены на другое лицо.

IT-проект может делиться по-разному.

Если есть доля в компании, предметом спора может быть доля или компенсация за неё.

Если есть иностранная компания, нужно анализировать местное право, cap table, корпоративные документы и реальную возможность исполнения.

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

Если есть SaaS с подписками, важно оценивать не только текущий остаток на счёте, но и MRR, ARR, churn, клиентскую базу, инфраструктуру, команду и перспективу дохода.

Если проект pre-revenue, оценка особенно спорная: будущая стоимость может быть большой, но она ещё не равна реальному совместному активу.

Часто практичная модель такая:

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

Главное — не превратить развод в технический саботаж.

Удалить репозиторий, заблокировать облако, сменить домен или поссорить команду проще, чем потом восстановить стоимость проекта.

Почему IT-бизнес сложно делить при разводе

IT-бизнес отличается от классического бизнеса тремя особенностями.

1. Активы цифровые

Код, домен, репозиторий, аккаунт в облаке, база пользователей, платежный аккаунт, аналитика, CRM, API-ключи и дизайн не лежат в сейфе.

Их можно потерять одним действием:

сменить пароль;
удалить репозиторий;
закрыть доступ;
перенести домен;
отключить сервер;
удалить billing;
заблокировать платежный аккаунт;
перевести продукт на новую компанию;
отключить команду;
забрать seed phrase или API-ключи;
перевести клиентов на другой домен.

Поэтому в IT-разводе доступы — это не мелочь.

Это часть контроля над активом.

2. Ценность может быть в будущем

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

Или не иметь оценки, но обладать перспективной технологией.

Или иметь MRR, который растёт каждый месяц.

Или быть pre-revenue, но с дорогой разработкой и сильной командой.

Проблема в том, что будущая оценка — это не деньги на счёте.

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

Но если в браке создан продукт, привлечены инвестиции, оформлены доли, подписан SAFE и есть реальный cap table, игнорировать это тоже нельзя.

Нужно отделять:

текущую стоимость;
последнюю инвестиционную оценку;
будущий потенциал;
риск провала;
фактическую выручку;
стоимость IP;
долю основателя;
ограничения по vesting;
обязательства перед инвесторами.

3. Право собственности часто не оформлено

В IT-проектах очень часто нет чистой юридической структуры.

Например:

код писали фрилансеры без договора;
разработчик ушёл, но права не передал;
дизайн сделал подрядчик без отчуждения прав;
домен оформлен на друга;
GitHub на личной почте;
сервер на карте супруги;
Stripe на иностранной компании;
приложение в App Store на аккаунте основателя;
инвестор дал деньги по переписке;
иностранная компания создана, но cap table не обновлён;
опционы обещаны в Telegram, но не оформлены;
часть кода взята из open source без анализа лицензии.

В таком проекте спорить о «стоимости стартапа» можно только после ответа на базовый вопрос: кому вообще принадлежит то, что создаёт стоимость.

Что может быть предметом спора

При разводе IT-предпринимателя, стартапера или владельца SaaS-проекта спор может идти сразу по нескольким группам активов.

1. Доля в российском ООО

Если IT-бизнес ведётся через российское ООО, предметом спора может быть доля в компании.

Нужно смотреть:

когда создано ООО;
кто участники;
какая доля принадлежит супругу;
приобретена ли доля в браке;
кто фактически управляет проектом;
есть ли другие основатели;
есть ли инвесторы;
есть ли корпоративный договор;
есть ли опционы или phantom shares;
есть ли выручка;
есть ли права на код у ООО;
есть ли договоры с разработчиками;
есть ли клиенты;
есть ли долги;
есть ли займы учредителя;
есть ли связанные иностранные компании.

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

Но передача доли второму супругу не всегда разумна.

Для IT-проекта это может создать:

конфликт с сооснователями;
нарушение инвестиционных документов;
риск deadlock;
риск раскрытия коммерческой тайны;
проблемы с инвесторами;
потерю доверия команды;
риск ухода CTO или ключевых разработчиков;
снижение оценки проекта.

Поэтому часто практичнее оставить долю основателю, а второму супругу выплатить компенсацию.

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

2. Доля в иностранной компании

У стартапов часто есть иностранная структура.

Например:

Delaware C-Corp;
компания в Сингапуре;
компания в ОАЭ;
компания в Гонконге;
компания на Кипре;
компания в Эстонии;
holding company за рубежом;
российская операционная компания плюс иностранный холдинг;
иностранная компания для Stripe, PayPal, App Store, инвесторов или международных клиентов.

В таком случае важно понять:

где зарегистрирована компания;
кто shareholder;
есть ли cap table;
кто directors;
какие акции или доли у супруга;
есть ли vesting;
есть ли restrictions on transfer;
есть ли shareholder agreement;
есть ли investor consent;
есть ли SAFE или convertible note;
есть ли option pool;
есть ли nominee;
есть ли связь с российским ООО;
где находится IP;
куда поступает выручка.

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

Но раздел такого актива сложнее.

Нужно учитывать:

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

В ряде случаев практичнее не требовать передачи акций иностранной компании, а считать компенсацию.

Но для этого нужно получить документы: cap table, stock purchase agreement, subscription agreement, SHA, SAFE, option documents, board approvals и переписку с инвесторами.

3. Опционы и vesting

Опционы — отдельная сложная тема.

У IT-предпринимателя может быть:

option grant;
stock options;
restricted stock;
RSU;
phantom shares;
founder vesting;
employee stock option plan;
право на долю при выполнении условий;
обещание доли в будущем;
доля, которая ещё не полностью «завестилась».

При разводе важно понять:

что именно у супруга есть сейчас;
это уже принадлежащие акции или право получить их в будущем;
есть ли vesting schedule;
сколько уже vested;
сколько unvested;
что будет при увольнении;
можно ли передавать опцион;
есть ли ограничения в документах;
есть ли strike price;
есть ли налоговые последствия;
когда получено право;
за какой период оно заработано;
связано ли оно с трудом супруга после фактического расставания.

Опционы нельзя механически делить как деньги на счёте.

Но они могут иметь имущественную ценность.

Особенно если компания уже привлекла инвестиции, имеет оценку и часть опциона уже vested.

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

Поэтому по опционам нужна отдельная финансово-правовая модель.

4. Код

Код — сердце IT-проекта.

Но сам факт, что супруг писал код, не всегда отвечает на вопрос, кому он принадлежит.

Нужно выяснить:

кто автор кода;
кто заказчик разработки;
был ли трудовой договор;
был ли договор подряда;
было ли отчуждение исключительных прав;
есть ли акты;
есть ли техническое задание;
есть ли служебное произведение;
есть ли договор с фрилансером;
есть ли договор с командой;
есть ли open source-компоненты;
есть ли коммиты;
где репозиторий;
кто owner репозитория;
кто имеет admin access;
есть ли forks;
есть ли private packages;
есть ли CI/CD;
связан ли код с коммерческим продуктом.

Главная ошибка — думать, что «код в GitHub основателя, значит код его личный».

Это не всегда так.

И обратная ошибка — думать, что «код писался в браке, значит половина кода принадлежит второму супругу».

Для раздела важнее не физическая копия кода, а исключительные права и экономическая стоимость продукта.

Если код принадлежит компании, нужно оценивать долю в компании.

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

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

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

5. Репозитории

GitHub, GitLab, Bitbucket и другие репозитории — это не просто место хранения кода.

Там может быть:

история разработки;
коммиты;
issues;
roadmap;
CI/CD;
secrets;
deploy keys;
доступы команды;
pull requests;
документация;
инфраструктурные скрипты;
private packages;
контракты с подрядчиками;
доказательства авторства;
доказательства сроков создания продукта.

При разводе репозиторий может стать источником доказательств.

Но с ним нужно обращаться осторожно.

Нельзя устраивать техническую войну:

удалять репозиторий;
менять права без необходимости;
блокировать команду;
публиковать private code;
скачивать коммерческую тайну без правового основания;
использовать доступы для давления;
ломать инфраструктуру.

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

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

6. Домены

Домен может быть критическим активом SaaS-проекта.

Например:

основной сайт;
landing page;
dashboard;
app domain;
API domain;
email domain;
домены для маркетинга;
домены для разных стран;
домены под бренд;
домены, через которые проходят платежи и авторизация.

Нужно смотреть:

кто registrant;
у какого регистратора домен;
на какую почту зарегистрирован;
кто оплачивает продление;
к какому бренду привязан;
есть ли товарный знак;
используется ли домен в продукте;
можно ли перенести домен;
не менялись ли DNS перед разводом;
не переводился ли домен на другое лицо;
не привязан ли домен к корпоративной почте и SaaS-инфраструктуре.

Домен не всегда является исключительным правом как товарный знак.

Но фактически он может быть ключом к бизнесу.

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

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

7. Аккаунты и доступы

В IT-бизнесе аккаунты могут быть важнее договора аренды офиса.

Критическими могут быть:

GitHub;
GitLab;
Bitbucket;
AWS;
Google Cloud;
Azure;
Cloudflare;
Vercel;
Netlify;
Heroku;
DigitalOcean;
App Store Connect;
Google Play Console;
Stripe;
Paddle;
PayPal;
Wise;
Mercury;
Brex;
OpenAI API;
Telegram bot;
Slack;
Notion;
Jira;
Linear;
Figma;
Webflow;
CRM;
email;
доменный регистратор;
рекламные кабинеты;
аналитика;
Amplitude, Mixpanel, GA;
support-система;
база клиентов.

Нужно понять:

кто владелец аккаунта;
кто платит;
чья почта используется;
есть ли 2FA;
кто admin;
кто может выгрузить данные;
кто может отключить продукт;
кто может изменить billing;
кто может удалить пользователей;
кто может поменять платежные реквизиты;
кто может перевести продукт на другую компанию.

Аккаунт сам по себе не всегда является имуществом в классическом смысле.

Но контроль над аккаунтом может означать контроль над бизнесом.

Поэтому в IT-разводе доступы нужно фиксировать и защищать.

8. Интеллектуальные права

Интеллектуальные права могут быть главным активом проекта.

К ним могут относиться:

исключительные права на программу для ЭВМ;
права на базу данных;
права на дизайн;
права на интерфейс;
права на тексты;
права на документацию;
права на логотип;
товарный знак;
права на ML-модель;
права на датасет;
права на контент;
права на API;
права на техническую архитектуру;
коммерческая тайна;
ноу-хау.

При разводе нужно выяснить:

кому принадлежат права;
как они возникли;
были ли договоры с авторами;
были ли акты передачи;
была ли регистрация программы для ЭВМ;
есть ли регистрация товарного знака;
есть ли договор отчуждения;
есть ли лицензии;
есть ли open source-обязательства;
есть ли права у иностранных подрядчиков;
есть ли права у бывших сотрудников;
не нарушаются ли чужие права.

Если права не оформлены, стоимость проекта может быть спорной.

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

Формально проект работает.

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

Для оценки это критично.

9. Open source и сторонний код

Многие IT-проекты используют open source.

Это нормально.

Но при разводе и оценке бизнеса нужно понимать:

какие библиотеки используются;
какие лицензии применяются;
есть ли copyleft-лицензии;
есть ли ограничения на коммерческое использование;
нужно ли раскрывать исходный код;
есть ли license compliance;
есть ли SBOM;
проверялся ли код перед инвестором;
есть ли риск претензий.

Если проект использует сторонний код с нарушением лицензий, его стоимость может снижаться.

Инвестор или покупатель может потребовать очистить IP.

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

10. SaaS-выручка: MRR, ARR и подписки

Для SaaS-проекта текущий остаток на счёте мало что говорит.

Важнее смотреть:

MRR;
ARR;
количество paying customers;
free users;
trial conversion;
churn;
retention;
gross margin;
ARPU;
LTV;
CAC;
burn rate;
runway;
expansion revenue;
refunds;
unpaid invoices;
payment failures;
annual contracts;
monthly subscriptions;
enterprise deals;
usage-based revenue.

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

Но если MRR растёт, это влияет на оценку.

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

Тогда оценка должна быть осторожной.

11. Валютный доход

IT-предприниматель часто получает доход в валюте.

Например:

USD;
EUR;
AED;
SGD;
HKD;
криптовалюта;
payments through Stripe, Paddle, PayPal, Wise;
иностранные банковские счета;
доход на иностранную компанию;
выплаты на личный счёт;
contractor payments.

При разводе важно понять:

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

Валютный доход нельзя анализировать только по рублёвым выпискам.

Нужно смотреть всю платежную цепочку.

12. Инвестиции

Стартап может привлечь инвестиции.

Это сильно усложняет развод.

Инвестиции могут быть оформлены как:

покупка доли;
SAFE;
convertible note;
займ;
грант;
revenue-based financing;
соглашение с ангелом;
акселератор;
investment agreement;
shareholder agreement;
side letter;
устная договорённость с инвестором.

Нужно понять:

кто получил деньги;
в какую компанию;
на каких условиях;
какая оценка проекта;
pre-money или post-money;
есть ли конвертация;
есть ли discount;
есть ли valuation cap;
есть ли liquidation preference;
есть ли запрет передачи доли;
есть ли обязательства перед инвестором;
есть ли право инвестора согласовывать сделки;
есть ли milestone;
есть ли риск возврата денег.

Инвестиционная оценка не всегда равна стоимости доли для раздела.

Например, инвестор вложил деньги по valuation cap 10 миллионов долларов.

Это не значит, что супруг уже может требовать половину от этой суммы.

Но инвестиционные документы являются сильным ориентиром.

Они показывают, как сам проект и инвестор оценивали перспективу на дату сделки.

13. Будущая оценка проекта

Самая спорная часть — будущая оценка стартапа.

Супруг может говорить:

«Через два года этот проект будет стоить 50 миллионов долларов».

Второй супруг может отвечать:

«Сегодня это убыточный продукт без прибыли».

Обе позиции могут быть неполными.

Для раздела важно различать:

мечту основателя;
investor deck;
последнюю оценку;
реальную сделку;
выручку;
прибыль;
MRR;
cap table;
обязательства;
риск провала;
dilution;
vesting;
зависимость от будущего труда основателя.

Будущая оценка может учитываться через текущую оценку доли и сценарии.

Но нельзя просто делить гипотетический unicorn exit, которого ещё нет.

Если проект станет дороже уже после развода за счёт нового труда, новых инвестиций, нового рынка и нового риска, вопрос будет сложнее.

Поэтому в соглашении иногда нужно отдельно прописывать:

фиксированную компенсацию сейчас;
earn-out;
доплату при exit;
доплату при продаже доли;
отказ от будущих претензий;
порядок раскрытия информации;
конфиденциальность;
предельные сроки и события.

Такие конструкции нужно готовить очень аккуратно.

14. Удалённая команда

SaaS-проект часто держится на удалённой команде.

Команда может находиться:

в России;
в СНГ;
в Европе;
в Азии;
в разных часовых поясах;
на фрилансе;
по трудовым договорам;
по contractor agreements;
через ИП или self-employed;
без нормальных договоров.

Для оценки важно понять:

кто ключевые разработчики;
есть ли CTO;
есть ли product manager;
есть ли designer;
есть ли DevOps;
есть ли customer support;
есть ли sales;
кто знает архитектуру;
кто имеет доступы;
кто может поддерживать продукт;
есть ли договоры;
переданы ли права;
есть ли NDA;
есть ли non-solicit;
есть ли риск ухода команды;
сколько стоит замена команды.

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

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

15. Данные и база пользователей

Данные могут быть активом, но с ограничениями.

В SaaS-проекте могут быть:

база пользователей;
база клиентов;
логи;
аналитика;
продуктовые метрики;
платежные данные;
user-generated content;
обучающие датасеты;
CRM;
support history;
email-листы;
рекламные аудитории.

При разводе нужно учитывать:

кому принадлежат данные;
где они хранятся;
какие есть политики;
какие согласия пользователей;
есть ли персональные данные;
есть ли коммерческая тайна;
можно ли выгружать данные;
можно ли передавать их второму супругу;
не нарушит ли это закон и договоры с клиентами.

Данные нельзя использовать как обычную папку с файлами.

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

Если IT-проект оформлен на иностранную компанию, а семья в России

Это типичный сценарий.

Например:

основатель живёт в России или был в России;
семья разводится в России;
продукт работает на международный рынок;
компания зарегистрирована в США;
Stripe подключён к иностранной компании;
GitHub на личной почте основателя;
команда в разных странах;
деньги поступают в валюте;
инвесторы смотрят на Delaware C-Corp.

В таком случае нужно разделять несколько уровней.

Семейный уровень

Российский суд или соглашение между супругами может оценивать, является ли доля, доход или иной актив совместно нажитым.

Корпоративный уровень

Иностранная компания живёт по праву своей юрисдикции.

Там могут быть ограничения на передачу акций, согласия совета директоров, инвесторов, ROFR, co-sale, vesting и другие механизмы.

Технический уровень

Контроль над продуктом может быть у лица, которое держит доступы, домен, репозиторий и платежные аккаунты.

Налоговый и валютный уровень

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

Поэтому в сложных кейсах важно не писать просто «делим иностранную компанию пополам».

Нужно понимать, что реально можно сделать:

передать часть доли;
выплатить компенсацию;
закрепить выплату при exit;
сделать залог;
подписать settlement agreement;
получить disclosure;
согласовать механизм с инвесторами;
использовать местных юристов по компании.

Если супруг выводит IT-проект перед разводом

IT-активы можно вывести очень быстро.

Например:

перенести репозиторий в новую организацию;
сменить owner GitHub;
передать домен;
поменять DNS;
создать новое ООО или иностранную компанию;
перевести платежи на новый Stripe;
переключить клиентов на новый домен;
забрать App Store или Google Play аккаунт;
удалить второго супруга из админов;
переписать код в новый репозиторий;
заменить бренд;
перевести команду;
заключить новые договоры с теми же клиентами;
обнулить старую компанию;
оформить IP assignment задним числом.

Если есть такие признаки, нужно фиксировать доказательства.

Важно сохранить:

сведения о доменах;
скриншоты сайта;
данные о приложении;
сведения о компании;
cap table;
историю коммитов;
данные о репозиториях;
invoices;
платежи;
переписку с инвесторами;
договоры с разработчиками;
документы по IP;
сведения о клиентах в агрегированном виде;
данные о MRR и ARR;
публичные материалы;
investor deck;
pitch deck;
рекламу;
вакансии;
LinkedIn-профили команды;
записи о релизах;
changelog.

Но фиксировать нужно законно.

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

В IT-разводе неправильная фиксация может сама создать проблему.

Как оценивать IT-бизнес, стартап или SaaS

Оценка IT-проекта должна учитывать несколько уровней.

Финансовые метрики

Для SaaS важны:

MRR;
ARR;
churn;
retention;
ARPU;
LTV;
CAC;
gross margin;
burn rate;
runway;
чистая прибыль;
выручка по клиентам;
доля enterprise-клиентов;
unpaid invoices;
refunds;
налоговая нагрузка;
комиссии платежных систем.

Продуктовые метрики

Смотрят:

активных пользователей;
DAU;
WAU;
MAU;
activation rate;
conversion;
engagement;
usage;
retention cohorts;
feature adoption;
support load;
roadmap;
technical debt.

IP-метрики

Смотрят:

кому принадлежит код;
есть ли договоры с авторами;
есть ли IP assignment;
есть ли open source-риски;
есть ли регистрация программы;
есть ли товарный знак;
есть ли домены;
есть ли спор с бывшими разработчиками.

Корпоративные метрики

Смотрят:

cap table;
доли основателей;
опционы;
vesting;
инвестиции;
debt;
SAFE;
convertible notes;
shareholder agreement;
ограничения на передачу;
dilution;
investor rights.

Командные метрики

Смотрят:

ключевых разработчиков;
CTO;
product;
sales;
support;
зависимость от основателя;
стоимость замены команды;
договоры;
риск ухода.

Рыночные метрики

Смотрят:

рынок;
конкурентов;
рост сегмента;
pricing;
каналы продаж;
географию клиентов;
вероятность масштабирования;
regulatory risk;
зависимость от платформ.

Главная цель оценки — не угадать будущий exit.

Главная цель — определить текущую обоснованную стоимость актива и разумную компенсацию.

Почему нельзя оценивать стартап по pitch deck

Pitch deck обычно показывает мечту.

Там может быть:

TAM;
SAM;
SOM;
прогноз выручки;
roadmap;
потенциальный рынок;
план привлечения инвестиций;
будущая оценка;
красивые графики.

Но pitch deck не равен стоимости бизнеса.

Для семейного спора нужно смотреть:

есть ли реальная сделка с инвестором;
есть ли подписанные документы;
есть ли поступившие деньги;
есть ли выручка;
есть ли клиенты;
есть ли код;
есть ли права на код;
есть ли команда;
есть ли долги;
есть ли риск закрытия проекта.

Pitch deck может быть доказательством позиции основателя о перспективах.

Но сам по себе он не должен заменять оценку.

Почему нельзя оценивать SaaS только по балансу

У SaaS на балансе может быть почти ничего.

Например:

ноутбуки;
10 000 рублей уставного капитала;
немного денег на счёте;
расходы на разработку;
нулевая прибыль.

Но при этом проект может иметь:

код;
подписки;
клиентов;
ARR;
домен;
бренд;
команду;
инвесторов;
данные;
продуктовую метрику;
перспективу роста.

И наоборот: баланс может показывать активы, но проект может быть мёртвым.

Поэтому оценивать SaaS только по бухгалтерскому балансу часто бессмысленно.

Нужно смотреть экономику продукта и права на него.

Если проект ещё не зарабатывает

Pre-revenue стартап — самый сложный случай.

Денег нет.

Прибыли нет.

Но есть:

код;
команда;
MVP;
домен;
бренд;
пользовательские тесты;
waitlist;
инвестиционные переговоры;
грант;
прототип;
договорённости с клиентами.

В такой ситуации стоимость может быть спорной.

Нужно смотреть:

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

Иногда pre-revenue проект действительно имеет стоимость.

Иногда это просто идея без отчуждаемых активов.

Если проект приносит доход после расставания

Частая ситуация: проект создан в браке, но резко вырос после фактического расставания.

Например:

в браке был MVP;
после расставания основатель привлёк инвестиции;
после расставания нанял команду;
после расставания вышел на рынок;
после расставания вырос MRR;
после расставания произошёл exit.

Это тонкий вопрос.

Нужно анализировать:

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

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

Но если основная ценность была создана в браке, игнорировать это тоже нельзя.

Соглашение о разделе IT-бизнеса

Если стороны готовы договариваться, соглашение часто лучше суда.

Особенно если нужно сохранить:

продукт;
команду;
инвесторов;
клиентов;
домены;
репозитории;
платежные аккаунты;
коммерческую тайну;
оценку проекта;
возможность привлечь следующий раунд.

В соглашении можно закрепить:

кому остаётся доля в компании;
кто получает компенсацию;
как определена стоимость проекта;
какие доли и иностранные компании учтены;
как учитываются опционы;
как учитываются инвестиции;
как учитывается будущий exit;
какие IP-активы раскрыты;
кому принадлежат домены;
кто контролирует репозитории;
какие доступы остаются у бизнеса;
как защищается конфиденциальность;
как стороны не вредят продукту;
как выплачивается компенсация;
что будет при продаже проекта;
что будет при следующем инвестиционном раунде;
какие претензии закрываются.

Плохая формулировка:

«Стартап остаётся мужу, жена претензий не имеет».

Хорошая конструкция должна быть конкретной.

Нужно описывать:

компанию;
долю;
иностранную структуру;
cap table;
опционы;
vesting;
код;
репозитории;
IP;
домены;
аккаунты;
платежные системы;
выручку;
инвестиции;
компенсацию;
сроки;
обеспечение;
конфиденциальность;
запрет вредить проекту.

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

Например:

продажа доли;
exit;
новый инвестиционный раунд;
достижение MRR;
получение дивидендов;
выкуп акций;
конвертация SAFE;
ликвидационное событие.

Когда лучше суд

Суд может быть лучше или неизбежен, если:

супруг скрывает долю;
не раскрывает cap table;
переводит код;
меняет owner репозитория;
переносит домен;
переводит клиентов;
создаёт новую компанию;
выводит выручку;
скрывает валютные счета;
оформляет IP на родственника;
подписывает документы задним числом;
скрывает инвестиции;
не раскрывает опционы;
предлагает подписать соглашение без оценки.

Суд может быть нужен, чтобы:

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

Но даже в суде нужно действовать аккуратно.

IT-проект легко повредить.

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

Типичные ошибки

Ошибка 1. Считать, что если бизнеса нет в ЕГРЮЛ, делить нечего

IT-проект может быть оформлен на иностранную компанию, физическое лицо, GitHub-организацию или вообще быть в стадии до нормальной структуры.

Это не значит, что активов нет.

Ошибка 2. Смотреть только на деньги на счёте

У SaaS главная ценность может быть в MRR, ARR, коде, IP, клиентах, домене и команде.

Ошибка 3. Не проверять права на код

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

Ошибка 4. Игнорировать домены и аккаунты

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

Потеря доступа может остановить бизнес.

Ошибка 5. Делить будущую оценку как уже полученные деньги

Будущий unicorn-exit — это не деньги на счёте.

Но инвестиционная оценка и cap table могут быть важными доказательствами.

Ошибка 6. Не учитывать опционы и vesting

Опцион может иметь ценность, но нужно понять, какая часть уже vested, а какая зависит от будущей работы.

Ошибка 7. Не видеть иностранную структуру

Доли в иностранной компании, SAFE, investor rights и ограничения на transfer нужно анализировать отдельно.

Ошибка 8. Ломать доступы

Удаление репозитория, блокировка облака, смена DNS или отключение платежей может уничтожить стоимость проекта.

Ошибка 9. Использовать клиентские данные как оружие

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

Ошибка 10. Подписывать соглашение без карты активов

Нельзя отказываться от претензий по IT-бизнесу, не увидев структуру: доли, IP, код, домены, выручку, инвестиции, опционы и доступы.

Что подготовить для консультации

Для первичного разбора желательно подготовить:

дату заключения брака;
дату фактического расставания;
дату создания проекта;
сведения о российском ООО;
сведения об ИП;
сведения об иностранной компании;
cap table;
shareholder agreement;
investment agreement;
SAFE;
convertible note;
option documents;
vesting schedule;
документы по долям;
документы по инвестициям;
сведения о доменах;
сведения о репозиториях;
список GitHub/GitLab/Bitbucket организаций;
документы по IP assignment;
договоры с разработчиками;
договоры с дизайнерами;
договоры с подрядчиками;
договоры с клиентами;
MRR;
ARR;
churn;
выручку по месяцам;
выписки по счетам;
данные Stripe, Paddle, PayPal или иных систем;
сведения о валютных поступлениях;
налоговую отчётность;
управленческий учёт;
pitch deck;
investor updates;
roadmap;
список ключевых сотрудников и подрядчиков;
данные по облачной инфраструктуре;
сведения о товарном знаке;
сведения о доменах;
информацию о рисках вывода активов;
предложения второй стороны.

Полезно начать с таблицы:

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

И отдельно:

компания — юрисдикция — доля — cap table — vesting — инвесторы — ограничения — оценка — риск — вариант компенсации.

Юрист по разводу IT-предпринимателя, стартапера или владельца SaaS

Развод IT-предпринимателя, стартапера или владельца SaaS-проекта требует не только знания семейного права.

Здесь важно понимать бизнес-логику:

код;
репозитории;
домены;
аккаунты;
облачную инфраструктуру;
интеллектуальные права;
программы для ЭВМ;
базы данных;
open source;
иностранные компании;
cap table;
опционы;
vesting;
инвестиции;
SAFE;
convertible notes;
MRR;
ARR;
валютную выручку;
удалённую команду;
коммерческую тайну;
оценку будущего роста;
риск навредить проекту самим конфликтом.

ZLATA LEGAL помогает по семейным и имущественным спорам, где развод связан с бизнесом, IT-проектами, SaaS, стартапами, иностранными компаниями, интеллектуальными правами, валютными доходами, инвестициями, опционами, долями и компенсациями.

Мы работаем во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России.

IT-бизнес при разводе нельзя оценивать только по балансу, уставному капиталу или остатку на счёте.

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

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

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

Делится ли IT-бизнес при разводе?

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

Делится ли стартап, если он ещё не приносит прибыль?

Да, он может иметь стоимость даже без прибыли, если есть код, продукт, команда, инвестиции, пользователи, IP или доля в компании. Но оценка будет сложнее.

Делится ли код при разводе?

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

Делится ли GitHub-репозиторий?

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

Что делать, если домен оформлен на одного супруга?

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

Делится ли доля в иностранной компании?

Да, она может учитываться как актив, но нужно анализировать право страны регистрации, cap table, ограничения на передачу и инвестиционные документы.

Как делятся опционы?

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

Учитывается ли будущая оценка стартапа?

Будущая оценка не равна уже полученным деньгам. Но инвестиционные документы, последняя оценка, MRR, ARR и перспективы могут влиять на размер компенсации.

Что такое SAFE при разводе?

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

Как учитывать валютный доход?

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

Что делать, если супруг переводит проект на новую компанию?

Нужно фиксировать доказательства: домены, репозитории, платежи, клиентов, новую структуру, команду, инвесторов, переписку и движение денег.

Можно ли заключить соглашение о разделе SaaS-проекта?

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

Что лучше: передать долю или выплатить компенсацию?

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

Как оценить SaaS-проект?

Нужно смотреть MRR, ARR, churn, клиентов, выручку, маржу, IP, команду, инфраструктуру, инвестиции, cap table, риски и зависимость от основателя.

Что делать, если права на код не оформлены?

Нужно проверять договоры с разработчиками, акты, IP assignment, историю коммитов и возможность оформить права. Без чистого IP стоимость проекта может быть ниже.

Какие документы нужны для раздела IT-бизнеса?

Нужны документы по компаниям, cap table, инвестиции, опционы, договоры с разработчиками, IP assignment, данные по репозиториям, доменам, платежам, MRR, ARR, валютным счетам и команде.

Что главное в таком споре?

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

Связанные материалы

Контакт

Обсудим ситуацию

Можно кратко описать обстоятельства спора и приложить документы, которые уже есть на руках.

Написать нам