Як провести аудит сайту чи цифрового продукту перед покупкою

Купівля сайту, SaaS-продукту, e-commerce бізнесу, маркетплейсу чи іншого цифрового продукту рідко зводиться до погляду на виручку і перевірки, чи гарний інтерфейс.

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

Ти купуєш не сайт. Ти купуєш систему, чиї проблеми стають твоїми в момент закриття угоди.

Ми бачили дорогу версію цього напряму, з клієнтом, що купив наявний e-commerce бізнес саме щоб відродити його. Ціна покупки включала сам сайт і його пошукові позиції, і ці позиції реально були сильними, просто повністю російською, в момент, коли українськомовний пошук вже ставав важливішим ринком.

Позиції були реальними. Технологія була реальною. Виручка була реальною. Проблема була в тому, що жодна з цих речей не означала того, що покупець думав, вона означає.

Під інтерфейсом сидів древній PHP з купою кастомних, самописних модулів, без документації, і неявне «розберись сам», залишене тим, хто це будував. Це був 2019 рік, до того як ШІ-інструменти могли реально допомогти проаналізувати чи розплутати такий легасі-код; просто ще не існувало такого шорткату.

Сайт врешті довелось повністю перебудувати з нуля. Товарні дані довелось перепарсити і перезаповнити, бо записи SKU були всипані помилками. Бізнес працював на старій російській 1С, що очевидно потребувала заміни. Аудит перед покупкою не проводився, і переплата, за сайт і за пошукові позиції, що не відповідали тому, куди реально рухався ринок, була величезною. Врешті роботу довелось робити знову.

Перш ніж купувати цифровий продукт, не питай, чи він тобі подобається. Питай, чи ти його розумієш.

ПОЧНИ З БІЗНЕСУ

Почни з бізнесу, не з коду

Перша помилка покупців, це відкрити сайт. Друга, відкрити вихідний код. Жодне з цього не має бути першим кроком.

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

Сайт з $500,000 річної виручки автоматично не вартий більше за той, що з $300,000. Якщо перший залежить від однієї рекламної платформи, одного співробітника, і пропрієтарної інтеграції, яку більше ніхто не розуміє, поки другий має диверсифіковане залучення, задокументовані процеси, і стабільний технічний фундамент, базовий профіль ризику повністю інший.

Аудит починається з простого питання: що саме генерує цінність? Лише після відповіді на це питання має сенс питати, чи технологія реально це підтримує.

ВИРУЧКА ТРАФІК СИГНАЛИ

Що генерує цінність: виручка й трафік як сигнали

Виручку варто розкладати, не подавати як одне вражаюче число.

Для e-commerce це означає відокремити валові продажі від чистих, середній чек, конверсію і повторні покупки, і виручку за товаром, каналом, географією. Для SaaS, це повторювана виручка, відтік, виручка від апсейлу, і наскільки виручка сконцентрована по акаунтах. Для лідогенерації, це вартість ліда, конверсія лід-у-продаж, і звідки реально приходять ліди.

Мета не лише перевірити цифри продавця. Це зрозуміти, як продукт реально заробляє. Сайт може мати мільйони відвідувачів і майже нульову економічну цінність, а інший, скромний трафік, що генерує дуже цінні ліди для спеціалізованої ніші. Трафік, це актив лише коли він звʼязаний з економічним результатом, і цей звʼязок треба перевіряти, не припускати.

Та сама дисципліна застосовується до самого трафіку. Сайт, що показує 200,000 відвідувачів на місяць сьогодні, виглядає повністю по-іншому залежно від того, чи цей трафік ріс стабільно три роки, чи впав з 500,000 шість місяців тому.

Для бізнесів, що керуються SEO, варто знати, наскільки бізнес залежить від невеликої кількості сторінок. Якщо 70% органічного трафіку йде з десяти URL, бізнес значно крихкіший, ніж підказує заголовна цифра, і одна алгоритмічна зміна чи помилка міграції може мати величезне значення.

ТЕХСТЕК ПІДТРИМУВАНІСТЬ

Технологічний стек і чи код реально підтримуваний

Лише після розуміння бізнесу має сенс відкривати технічну архітектуру. Мета, повна карта залежностей: мови, фреймворки, база даних, хостинг, API, платіжні системи, сторонні бібліотеки, заплановані завдання, все, від чого продукт реально залежить, щоб функціонувати.

Здавалося б простий e-commerce сайт може реально залежати від ланцюга, що йде від фронтенду через API, шар застосунку, базу даних, платіжного провайдера, ERP, системи інвентарю й доставки, email, аналітику, і сторонній пошуковий сервіс. Якщо будь-яка одна ланка в цьому ланцюзі погано задокументована чи не підтримується, придбання успадковує цей ризик напряму.

Саме в цю стіну врізалось придбання e-commerce 2019 року. Кастомні PHP-модулі не мали документації і жодного пояснення на прощання, окрім неявного очікування, що хтось врешті розбереться.

Сьогодні ШІ-асистований аналіз коду може суттєво скоротити цей процес відкриття. Він може допомогти технічному рев'юеру зрозуміти, що реально робить легасі-система, швидше за ручне трасування самотужки. Він все ще не може замінити реальний аудит, і не перетворює недокументований код на задокументований, але поріг того, що можна виявити перед покупкою, значно вищий сьогодні, ніж тоді.

Код не має бути гарним. Він має пережити людину, що його написала, залишивши кімнату.

Реальне питання, варте запитання, чи міг би компетентний розробник перейняти систему самостійно. Якщо чесна відповідь ні, покупець не набуває самодостатнього цифрового продукту. Він набуває залежність від конкретної людини, і ця залежність має реальну ціну.

ІНФРАСТРУКТУРА БЕЗПЕКА

Інфраструктура, деплой і безпека

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

Це означає перегляд хостингу, середовищ, бекапів, disaster recovery, DNS, моніторингу, і самого процесу деплою, і прохання комусь пройти через цей процес від початку до кінця.

«Ми зазвичай заходимо по SSH на сервер і міняємо вручну» описує суттєво інший операційний ризик, ніж задокументований CI/CD пайплайн з можливістю відкату, навіть коли обидва технічно працюють сьогодні.

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

Безпека заслуговує на ту саму ретельність, оскільки придбання включає акаунти клієнтів, платіжну інформацію, пропрієтарні бізнес-дані, і креденшли, не лише код.

Два питання варті прямого й конкретного запитання: чи продукт колись зламували чи компрометували, і хто зараз має доступ до продакшену? Друге питання пропускають частіше, ніж варто. Бізнес може мати реально сильний контроль безпеки і все одно мати жменьку колишніх підрядників з активними серверними креденшлами, про які ніхто не згадав відкликати.

БАЗА ДАНИХ

База даних і дані

Для багатьох цифрових бізнесів база даних, один з найцінніших активів, і її цінність повністю залежить від якості.

Придбання 2019 року зробило це конкретним дорогим способом. Товарні записи були всипані помилками SKU й неузгодженостями, накопиченими за роки ad-hoc змін, і покупець врешті перепарсив і перезаповнив товарний каталог фактично з нуля, роботу, яку мали б закласти в початкову угоду, не виявити пізніше.

Структурні проблеми мають тенденцію накопичуватись тихо. Якщо інформація про клієнтів існує в кількох незалежних системах з неузгодженими ідентифікаторами, міграція стає дорогою способами, які важко оцінити наперед. Якщо товарні дані сильно залежать від кастомних полів, накопичених за роки, перехід на нову платформу може вимагати значної реконструкції, не простого експорту. І якщо аналітику не можна узгодити з транзакційними даними, бізнес може мати труднощі навіть довести власну історичну ефективність переконливо.

Дані, це і актив, і зобов'язання, і яким з них вони виявляться, зазвичай не видно ззовні.

SEO КРИХКИЙ АКТИВ

Контент і SEO як крихкий актив

Якщо придбання включає контентно-важкий сайт, сама кількість сторінок означає майже нічого.

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

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

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

Кейс 2019 року, найясніша можлива ілюстрація цього. Запитувана ціна продавця явно включала сильні пошукові позиції, і ці позиції були реальними, просто сконцентрованими майже повністю в російськомовному пошуку, точно в момент, коли ринок зсувався до українськомовного попиту, що ставав комерційно важливішим.

Позиції були реальним активом на одному ринку і майже нерелевантним на тому, де бізнесу реально потрібно було конкурувати надалі.

Видимість, що не відповідає тому, куди реально рухається попит, не той актив, яким вона здається на папері. Саме такий розрив реальний аудит покликаний виявити перед покупкою, не після, той самий принцип, розібраний з боку побудови у мультимовному AEO.

UX ПРОДУКТИВНІСТЬ

UX, конверсія і продуктивність

Цифровий продукт може технічно функціонувати ідеально і все одно бути комерційно неефективним.

Проходження реального шляху клієнта, лендинг до категорії до товару до кошика до чекауту для e-commerce, чи лендинг до реєстрації до активації до утримання для SaaS, розкриває, де користувачі йдуть, де зайве тертя, і де досвід ламається між пристроями.

Аналітика показує, що щось відбувається. Юзабіліті-огляд допомагає пояснити що.

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

Корисне питання ніколи не було просто «чи сайт швидкий». Це чи є значуща проблема продуктивності, і скільки реально коштувало б її виправити.

СТОРОННІ ЗАЛЕЖНОСТІ

Сторонні залежності

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

Для кожного зовнішнього сервісу, від якого залежить продукт, варто знати, хто володіє акаунтом, хто за нього платить, чи контракт реально переноситься, і чи акаунт взагалі може перейти до нового власника.

Стара російська 1С під придбанням 2019 року була саме такою залежністю: система, що явно потребувала заміни, привʼязана до інфраструктури й ліцензування, які новий власник не мав реального шляху просто успадкувати.

$500-на-місяць зовнішній API, керована вартість. Той самий API, привʼязаний до особистого агентського акаунту продавця, без переносного контракту, перетворює ідентичне технічне налаштування на повністю іншу фінансову й операційну проблему в момент, коли володіння змінюється.

ІНТЕЛЕКТУАЛЬНА ВЛАСНІСТЬ

Інтелектуальна власність

Володіння часто складніше, ніж очікують покупці.

Вихідний код, дизайни, фотографії, копірайтинг, торгові марки, домени, і пропрієтарні алгоритми всі потребують чіткого, перевірюваного власника, не припущеного.

Якщо продукт будувала агенція, варто напряму підтвердити, що продавець реально володіє результуючим кодом, не просто має ліцензію на використання. Якщо долучались фрилансери, документи про передачу інтелектуальної власності мають існувати і мають бути перевірені, не прийняті на віру.

Покупець не має виявити після закриття, що «пропрієтарна платформа» тихо містить код, на продаж якого продавець ніколи реально не мав права.

ЛЮДИ І ЗНАННЯ

Люди і знання: що станеться, коли одна людина піде

Деякі цифрові продукти, це справжні софтверні бізнеси. Інші, бізнеси у формі софту, що реально керуються вручну за лаштунками однією-двома людьми, що просто знають, де все лежить.

Ми бачили цей паттерн, що зʼявляється в контексті due diligence, майже в тій самій формі, що й ширша проблема корпоративних систем, що почались як чиясь таблиця, кожна корпоративна система почалась з чиєїсь таблиці, тільки тут ставки були придбанням, не внутрішнім процесом.

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

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

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

РЕАЛЬНА ВАРТІСТЬ

Реальна вартість володіння і перебудови

Виручка показує, що приходить. Аудит має встановити, що реально йде: хостинг, підписки, API, розробка, підтримка, саппорт, реклама, розділені на суттєві витрати проти опційних.

Продавець, що звітує $8,000 на місяць операційних витрат, може означати, що $3,000 з цього, непов'язана особиста витрата, а $4,000, підрядник, що виявляється єдиною людиною, що знає, як тримати платформу працюючою.

Число, що реально важить, не історичні витрати. Це реалістична майбутня вартість експлуатації продукту після закриття придбання.

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

Продукт може мати $200,000 реально корисної технології і все одно вимагати $80,000 негайної роботи. Це не означає, що продукт вартий $120,000, але покупцю абсолютно потрібно розуміти цю необхідну інвестицію до погодження ціни, не після, точно та сама дисципліна, розібрана ширше у рівнянні будувати проти купувати.

КАРТА РИЗИКІВ

Аудит має виробити карту ризиків, не звіт, що ніхто не читає

Сорокасторінковий технічний звіт, що ніхто реально не читає, не корисний результат. Знахідки потрібно перекласти на бізнес-наслідки, у формі, достатньо конкретній, щоб вести переговори проти неї.

Приклад карти ризиків

Мета ніколи не була виробити оцінку. Це зробити невідоме видимим, письмово, до того як воно стане проблемою покупця замість переговорів.

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

ЩО ТИ КУПУЄШ

Що ти реально купуєш

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

Сайт, один компонент. Код, база даних, SEO, клієнти, інфраструктура, інтеграції, контент, процеси, і інтелектуальна власність, все робить внесок у те, що реально купується.

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

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

Гарний сайт може приховувати слабкий бізнес. Застарілий може приховувати реально цінний цифровий актив. І технічно вражаючий продукт все одно може бути поганим придбанням, якщо ніхто реально не знає, як ним керувати без оригінального творця поруч.

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

Чим аудит цифрового придбання відрізняється від стандартного технічного аудиту?

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

Скільки часу зазвичай займає належний аудит цифрового продукту?

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

Чи можна провести цей аудит самостійно, чи потрібна зовнішня допомога?

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

Яка найбільша помилка, що роблять покупці в цифровому придбанні?

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

Чи ШІ робить такий аудит швидшим чи менш потрібним сьогодні?

Швидшим у місцях, не менш потрібним. ШІ-асистований огляд коду може суттєво прискорити розуміння легасі-кодової бази, чогось, що просто не існувало ще кілька років тому. Він не заміняє перевірку володіння, перевірку реального доступу до інфраструктури, чи підтвердження, що дані й позиції реально переносяться до нового власника.