«Нам нужны просто оферта и политика»: как один запрос юристу привел к переписыванию бэкенда стартапа
Почему код нужно писать под юридическую модель, а не наоборот?
Всем привет! С вами Георгий Трельский - юрист для IT и креативного бизнеса.
На днях пришел запрос от Project-менеджера. Стартап на стадии Pre-MVP: маркетплейс для архитекторов. Задача звучала стандартно: «Мы скоро запускаемся, сделайте нам документы для сайта и скажите, какие логи хранить».
Казалось бы, бери шаблон и заполняй. Но проведенный Legal & Tech Audit показал, что стандартный подход здесь убьет проект через 2 месяца: либо от блокировки счета банком, либо от невозможности доказать правоту в суде.
Разбираю на реальном кейсе, почему в 2026 году юрист должен лезть в API и архитектуру базы данных.
Проблема №1. «Прикрутим эквайринг на ИП» vs Блокировка по 115-ФЗ
Дано: клиент хочет подключить стандартный интернет-эквайринг (условный базовый тариф RoboKassa) на свое ИП.
Схема: заказчик платит 100% суммы, деньги падают на счет ИП, владелец оставляет себе комиссию и переводит остаток архитектору.
В чем риск? Для банка и налоговой это выглядит так:
- Транзит (115-ФЗ): вы принимаете деньги от физлиц и тут же рассылаете их другим физлицам. Это «красный флаг» для финмониторинга, который трактуется как обнал. Блокировка счета гарантирована.
- Налоги: ФНС посчитает налогооблагаемой базой всю сумму, зашедшую на счет, а не только вашу комиссию. Вместо 6% с прибыли вы заплатите 6% с оборота.
Решение (Архитектурное): юрист запрещает стандартную интеграцию. Необходимо внедрение Сплит-системы (Yandex Split, T-Bank, CloudPayments, Robo.Market) или работа через Номинальный счет.
Суть: деньги «замораживаются» и расщепляются еще на стороне банка/агрегатора. Вам падает комиссия, исполнителю - оплата. На ваш расчетный счет чужие средства не попадают.
Боль для разработки: это нельзя сделать «по кнопке» в личном кабинете платежки. Переход на сплитование требует сложной backend-интеграции API. Если не заложить это на старте, переделка биллинга займет 100–150 часов работы разработчика уже после запуска MVP.
Проблема №2. «Логи в .txt» vs Доказательства в суде
Дано: PM спрашивает: «Какие действия логировать, чтобы потом доказать, что услуга оказана?». Обычно админы пишут логи в текстовые файлы или JSON.
В чем риск: в суде обычный лог разбивается одним аргументом ответчика: «Истец (администратор сайта) сам нарисовал этот файл». Текстовый файл без обвязки - не доказательство. А если писать туда ФИО пользователей, то логи становятся базой персональных данных, требующей высшего уровня защиты.
Решение (Legal & Tech):
- АСП (Аналог подписи): в Оферту внедряем раздел, приравнивающий клик или ввод кода к собственноручной подписи.
- Целостность: фиксируем не просто факт действия, а хэш передаваемого файла + Timestamp, привязанный к сессии.
- Псевдонимизация (152-ФЗ): в системные логи запрещено писать ФИО («Иванов загрузил файл»).
Как надо: в логи пишем User_UUID. Таблица связки UUID с ФИО хранится в отдельном изолированном контуре базы данных. Это снижает класс защищенности логов и минимизирует ущерб при возможной утечке.
Проблема №3. Шифрование и ловушка с лицензией ФСБ
Дано: стартап хочет защитить чертежи и гарантировать конфиденциальность. Решение разработчиков - шифровать базу данных стандартом AES-256.
В чем риск: если вы напишете в рекламе или Оферте: «Мы предоставляем услугу защищенного шифрованного хранения», вы рискуете попасть под требование о лицензировании деятельности в области криптографии со стороны ФСБ.
Решение: в документах и позиционировании четко прописываем: шифрование - это внутренняя техническая мера обеспечения безопасности платформы, а не оказываемая услуга третьим лицам. Технически делаем то же самое, но юридически выводим бизнес из-под удара регулятора.
Итог: сколько стоит «просто документ»?
Изначальный запрос на «пакет документов» трансформировался в изменение архитектуры проекта.
- Если бы мы просто написали оферту за 20 000 р., стартап бы запустился, но получил бы блокировку счета и попал на налоги со всего оборота.
- Комплексное проектирование (Legal & Tech Architecture) стоит дороже, но оно экономит сотни тысяч рублей на переписывании кода (Refactoring) и спасает бизнес от остановки.
Вывод для фаундеров: в сложных нишах (FinTech, Marketplaces, SaaS) код пишется под юридическую модель. Не пытайтесь натянуть шаблонную оферту на уже написанный продукт - рискуете переписывать продукт целиком.
Подписывайтесь на мой тг-канал, где я разбираю сложные IT - кейсы, пишу о создании правовой архитектуры и privacy (152-ФЗ) для бизнеса с инженерной точностью.