Юридическая защита стартапа: что проверить до запуска и инвестиций

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

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

Начните с договоренностей между основателями

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

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

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

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

основатели согласуют роли и условия работы

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

Составьте карту происхождения активов

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

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

Не смешивайте защиту бренда и доступ к аккаунтам

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

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

Заключайте договоры под реальный способ работы

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

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

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

Проверьте данные и публикации до роста аудитории

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

Помимо данных клиентов, стартап обрабатывает сведения о сотрудниках, кандидатах и контактных лицах заказчиков. Составьте перечень данных, целей и сроков хранения, сервисов-получателей и стран, где происходит обработка. Проверьте основания для сбора данных, необходимые уведомления и согласия, порядок ответа на запросы субъектов и договоренности с подрядчиками. Если проект работает в России, отдельно оцените применимость требований о локализации и уведомлении уполномоченного органа. На других рынках могут действовать дополнительные правила.

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

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

команда проверяет доступ к данным проекта

Контент и заявления о продукте

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

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

Подготовьте компанию к инвестициям без лишних обещаний

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

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

Расставьте приоритеты при ограниченном бюджете

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

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

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

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