Как провести аудит сайта или цифрового продукта перед покупкой

Покупка сайта, 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 пайплайн с возможностью отката, даже когда оба технически работают сегодня.

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

Безопасность заслуживает той же тщательности, поскольку приобретение включает аккаунты клиентов, платёжную информацию, проприетарные бизнес-данные, и credentials, не только код.

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

БАЗА ДАННЫХ

База данных и данные

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

Приобретение 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, инфраструктура, и зависимости от людей все реально перенестись к новому владельцу, тихо не развалившись в процессе.

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

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

Можно ли провести этот аудит самостоятельно, или нужна внешняя помощь?

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

Какая самая большая ошибка, что делают покупатели в цифровом приобретении?

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

Делает ли ИИ такой аудит быстрее или менее нужным сегодня?

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