Чек-лист due diligence застосунку: що перевіряє покупець перед купівлею

Due diligence звучить важко, але для більшості невеликих застосунків це цілеспрямована перевірка того, що цифри справжні й нічого не збирається зламатися. Це список, за яким я йду, коли переглядаю застосунок. Скористайтеся ним, щоб підготуватися ще до розмови з будь-яким покупцем: упорядкована папка заощаджує дні й робить ваші цифри переконливішими.

Як підтвердити дохід застосунку?

Експортами з першоджерел, а не таблицею, яку ви заповнили вручну. Покупці хочуть бачити:

• Звіти App Store Connect Sales and Trends і Payments and Financial Reports за останні 12–24 місяці.
• Для застосунків з підписками огляд у RevenueCat (чи аналогу): MRR, активні підписки, конверсія з пробного періоду, продовження, відтік і повернення коштів. Про підписки під час продажу докладно в статті як продати застосунок з підписками.
• Банківські виписки чи записи про виплати, що збігаються з виручкою; корисно для більших угод.
• Будь-який інший дохід: реклама, вебпокупки, спонсорство.

Як покупці перевіряють витрати й прибуток?

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

• Рекламні витрати за каналами (Apple Search Ads, Meta, TikTok, Google) з відповідними встановленнями (дивіться як продати застосунок, що росте на платній рекламі).
• Сервери, API, витрати на AI/LLM, програмні інструменти, підрядники й підтримка. Для AI-застосунків помісячні витрати на API покупці дивляться насамперед: як продати AI wrapper застосунок.
• Проста помісячна таблиця доходів і витрат.

Те, що покупець тут знайде, напряму впливає на мультиплікатор: у статті скільки коштує мій застосунок пояснено, які знахідки його підвищують, а які знижують. Щоб отримати швидкий діапазон ще до розмов, спробуйте калькулятор вартості застосунку.

Які дані про трафік і користувачів потрібні покупцям?

Звідки беруться завантаження і чи залишаються користувачі. Конкретно:

• App Analytics: покази, перегляди сторінки продукту, завантаження і типи джерел (пошук в App Store, перегляд розділів, переходи з вебу, переходи з інших застосунків).
• Головні ключові слова, за якими ви ранжуєтеся, і головні країни.
• Утримання й активні користувачі, якщо ви їх відстежуєте.

Що покупці перевіряють у коді й продукті?

Чи може застосунок працювати без вас і чи не збирається щось зламатися.

• Технологічний стек, мінімальна версія ОС і те, як збираються й випускаються білди.
• Сторонні SDK і сервіси, і хто власник кожного акаунта.
• Частота збоїв і відомі баги.
• Усе, що залежить від вас особисто, наприклад сервер на вашому власному компʼютері чи особистий API-ключ.
• Сам код покупці зазвичай дивляться лише після того, як пропозицію погоджено, або під NDA.

Які перевірки історії в App Store і юридичних питань бувають?

Минулі проблеми з магазином і підтвердження того, що ви володієте тим, що продаєте.

• Минулі відхилення, попередження чи видалення і їхні причини.
• Історія відгуків і оцінок. Відгуки за винагороду або куплені відгуки для більшості покупців означають кінець угоди.
• Права на назву, логотип, домен і торговельні марки, якщо вони є.
• Ліцензії на шрифти, зображення, звуки й сторонній код.
• Політика конфіденційності і те, як зберігаються дані користувачів.
• Чи відповідає застосунок правилам передачі. Критерії Apple (нічого не на перевірці, TestFlight вимкнено, немає дублікатів ідентифікаторів продуктів) наведено в моєму посібнику про передачу застосунку в App Store.

Як безпечно ділитися даними?

Під NDA, через демонстрацію екрана або скриншоти, і ніколи не передаючи пароль від Apple Account.

• Спершу підпишіть NDA, якщо ділитеся детальними цифрами.
• Надавайте перевагу демонстрації екрана й скриншотам, а не логінам. Якщо покупцю потрібен прямий доступ, дайте найобмеженіший доступ, який дозволяють ваші інструменти, і потім заберіть його.
• Ніколи не передавайте пароль від Apple Account чи сам акаунт розробника.

Які тривожні сигнали зривають угоди?

Цифри, що не сходяться, і проблеми, які спливають пізно.

• Цифри, що не збігаються між різними джерелами.
• Раптовий стрибок прямо перед продажем, зазвичай через платну рекламу, яку от-от вимкнуть.
• Неоголошені проблеми, знайдені пізно: попередження від App Review, закриття ключового SDK, юридичний спір.
• Дохід, що залежить від засновника особисто, як-от клієнтська робота чи особиста аудиторія.

Розкажіть про це заздалегідь. Відому проблему враховують у ціні; прихована проблема закінчує угоду. Після due diligence наступний крок це оплата: дивіться escrow під час продажу застосунку.