Ключевые риски при приобретении готового IT-продукта
Покупка готового мобильного приложения — это сделка по передаче нематериального актива, где основные риски скрыты в «подкапотной» части продукта. Основные угрозы включают:
1. Наличие «закладок» и бэкдоров. Разработчик может оставить скрытые функции для удаленного доступа к базе данных пользователей или управления функционалом приложения после его передачи новому владельцу.
2. Использование нелицензионных библиотек. Если в коде применены компоненты с «вирусными» лицензиями (например, GPL), вы рискуете получить требование об открытии исходного кода всего вашего продукта.
3. Отсутствие прав на интеллектуальную собственность. Продавец может не обладать исключительными правами на все части кода, если они были написаны фрилансерами без оформления договоров об отчуждении прав.
4. Технический долг. Приложение может работать, но быть написано на устаревших фреймворках, которые не поддерживают актуальные версии iOS или Android, что потребует полной переработки кода в течение 6–12 месяцев.
5. Зависимость от сторонних API. Если приложение жестко привязано к платным сервисам или ключам разработчика, при смене владельца функционал может мгновенно отключиться.
Технический аудит: как проверить качество и безопасность исходного кода
Технический аудит должен проводиться независимым экспертом или командой разработчиков, не связанной с продавцом. Проверка включает следующие этапы:
* Анализ безопасности (SAST/DAST). Используйте инструменты автоматизированного сканирования (например, SonarQube, MobSF) для поиска уязвимостей в коде. Проверьте соответствие стандарту OWASP Mobile Application Security Verification Standard (MASVS).
* Проверка зависимостей. Просканируйте файл `package.json` (для React Native), `build.gradle` (для Android) или `Podfile` (для iOS) на наличие устаревших библиотек с известными уязвимостями (CVE).
* Анализ архитектуры. Оцените чистоту кода (Clean Code). Если проект написан «на коленке» без документации и модульности, стоимость его масштабирования будет выше стоимости разработки с нуля.
* Тестирование инфраструктуры. Проверьте, где хранятся ключи API, сертификаты и данные пользователей. Они не должны быть «зашиты» в код (hardcoded).
* Доступ к репозиторию. Убедитесь, что вам передают полный доступ к истории коммитов в Git. Отсутствие истории — признак того, что код мог быть скопирован или сгенерирован автоматически.
Юридическая проверка прав на интеллектуальную собственность
Юридическая чистота сделки важнее технической, так как без прав на код вы не сможете защитить бизнес в суде.
1. Договоры с разработчиками. Запросите у продавца цепочку договоров: от штатных сотрудников или фрилансеров к компании-продавцу (договоры авторского заказа или трудовые договоры с пунктом об отчуждении прав).
2. Реестр ПО. Проверьте, внесено ли приложение в Единый реестр российских программ для ЭВМ (если актуально для вашего рынка). Это подтверждает статус продукта как объекта интеллектуальной собственности.
3. Товарный знак. Убедитесь, что название приложения и логотип зарегистрированы как товарный знак. Если нет, проверьте по базе ФИПС, не нарушаете ли вы права третьих лиц.
4. Акт приема-передачи. Сделка должна сопровождаться актом, в котором четко прописан перечень передаваемых объектов: исходный код, документация, права на доменное имя, аккаунты в App Store и Google Play.
Безопасные сценарии оплаты: эскроу-счета и поэтапные транзакции
Никогда не переводите полную сумму на личную карту продавца до завершения всех проверок.
* Эскроу-счет (Escrow). Это самый безопасный метод. Вы переводите деньги на специальный счет независимого посредника (банка или специализированного сервиса). Деньги блокируются и перечисляются продавцу только после того, как вы подтвердите получение доступа к репозиторию, серверам и правам на аккаунты.
* Поэтапная оплата (Milestones). Разбейте платеж на части: 30% — аванс, 40% — после успешного технического аудита, 30% — после полной передачи прав и смены владельца в сторах.
* Аудит перед оплатой. Оплату за аудит (обычно 5–15% от стоимости сделки) берет на себя покупатель, но эти расходы должны быть вычтены из итоговой стоимости покупки при успешном завершении сделки.
Когда покупка готового решения несет критические угрозы
Покупка готового приложения может стать фатальной ошибкой в следующих случаях:
1. Отсутствие исходного кода. Если продавец предлагает только скомпилированный файл (APK/IPA) без доступа к исходникам, вы покупаете «черный ящик», который невозможно развивать.
2. Привязка к «серому» трафику. Если приложение имеет высокую посещаемость, но она накручена ботами, вы рискуете получить бан от рекламных сетей и сторов сразу после покупки.
3. Юридические споры. Если в отношении продавца или самого продукта ведутся судебные разбирательства по авторским правам, вы наследуете эти риски вместе с кодом.
4. Устаревший стек. Если приложение написано на технологиях, которые перестали поддерживаться (например, старые версии Cordova или Ionic), затраты на миграцию могут превысить стоимость покупки в 2–3 раза.
Для продолжения темы — проверить безопасность и условия оплаты при.