Техническая проверка Micro-SaaS при покупке у соло-разработчика

Micro-SaaS, который создает один разработчик, может оказаться удачной покупкой именно благодаря своему небольшому размеру. В кодовой базе можно разобраться, обещание клиенту обычно четко очерчено, а операционные расходы видны. Но та же концентрация создает главный риск: продукт, рабочая система, очередь поддержки, платежный аккаунт и вся история общения с клиентами могут существовать только в голове одного человека и его личных учетных записях.

Покупателю не стоит выяснять, похож ли код на код крупной компании. Такой критерий отбрасывает выгодную простоту и все равно пропускает опасные места. Нужно понять, сможет ли другой компетентный человек управлять бизнесом без памяти продавца, его учетных данных и ежедневных решений. Разницу между нынешним положением и доказанным ответом «да» следует учесть в цене.

Хорошая техническая проверка Micro-SaaS перед покупкой отделяет дефекты, которые можно исправить после сделки, от зависимостей, которые мешают получить контроль в день закрытия. Неаккуратные модули обычно поправимы. Домен, который нельзя передать, неописанное восстановление данных или платежная схема, привязанная к личности продавца, способны остановить бизнес. Это различие должно определять ход проверки, условия договора и календарь передачи.

Вы покупаете систему управления, а не репозиторий

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

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

• Компания, домен, товарные знаки и договоры с клиентами
• Репозитории исходного кода, реестры пакетов, системы сборки и учетные записи для развертывания
• Облако, базы данных, хранилища, отправка писем, мониторинг и доступ к поддержке
• Платежный сервис, настройки банковских выплат, налоговые записи и данные подписок
• Аналитика, документация, макеты, маркетинговые каналы и лицензии сторонних поставщиков

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

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

Первым результатом проверки должен стать реестр контроля, а не текстовый отчет. Достаточно таблицы, если в каждой строке есть владелец, подтверждение, срок и признак блокировки сделки. Все, что помечено как «личный аккаунт продавца», требует явной проверки передачи до оплаты.

Риск непрерывности скрыт в решениях, которых нет в коде

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

Начните с истории Git, потому что она быстро дает исходную картину. Выполните эти команды в полном клоне, а не в архиве с исходниками:

git shortlog -sne HEAD
git log -n 500 | sed -n 's/^Author: //p' | sort | uniq -c | sort -nr
git log -1

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

Затем составьте карту повторяющихся решений. Попросите продавца рассказать о последнем развертывании, сбое, возврате, неудачном платеже, проверке резервной копии, обновлении зависимости и сложном обращении в поддержку. Для каждой истории запросите реальный тикет, историю команд, событие в журнале или запись у провайдера. Гладкое руководство, написанное специально к продаже, сообщает меньше, чем неопрятный тикет, где видно поведение системы под нагрузкой.

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

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

Быстрая проверка кода должна идти по путям отказа

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

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

Сосредоточенную проверку можно провести в пять проходов:

1. Воспроизведите сборку и тесты на чистой машине или во временной среде, следуя только инструкциям из репозитория.
2. Проследите одно успешное и одно неудачное действие клиента по журналам, записям базы, очередям и уведомлениям.
3. Проверьте аутентификацию, административные функции, разделение клиентов, валидацию ввода, загрузку секретов, экспорт и удаление данных.
4. Перечислите прямые и транзитивные зависимости, их версии, лицензии, состояние обновлений и пакеты, полученные в обход обычного менеджера пакетов.
5. Сравните развернутый артефакт и его конфигурацию с проверенным коммитом.

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

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

Стандарт OWASP Software Component Verification Standard требует большего, чем «запустить сканер уязвимостей». В разделе об инвентаризации сказано, что к концу сборки должны быть известны прямые и транзитивные компоненты с версиями, а список должен существовать в точном машиночитаемом виде. Для покупки компании я согласен с этим требованием, но применял бы его соразмерно: небольшому продукту нужен воспроизводимый список зависимостей и контроль над закрытыми пакетами, а не неделя формальной работы с документами по безопасности.

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

Система должна работать без ноутбука продавца

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

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

Резервные копии требуют настоящего восстановления, а не зеленой отметки в панели. Создайте изолированное место под контролем покупателя, восстановите туда последнюю копию и выполните значимые для продукта проверки: количество строк, доступ к вложениям, границы между клиентами, ссылки на подписки и тестовый вход. Запишите фактическую точку восстановления и затраченное время. Не принимайте целевые показатели из документа, если их никто не проверял.

Рассмотрим сбой, с которым я встречался в нескольких вариантах. База приложения копируется каждую ночь, поэтому панель показывает нормальное состояние. Загруженные клиентами файлы лежат в объектном хранилище другого личного облачного аккаунта, а база содержит лишь пути к объектам. Покупатель успешно восстанавливает базу, видит тысячи корректных записей и обнаруживает отсутствие всех документов клиентов. Перечень сервисов выявил бы второе хранилище, а проверка восстановления доказала бы потерю до сделки.

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

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

Проверка безопасности должна доказать изоляцию и восстановление

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

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

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

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

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

Обещания клиентам могут быть важнее публичного плана

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

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

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

Для старых условий нужно принять явное решение. Сохранять прежний тариф может быть дешево, если все обслуживаются одним путем в коде. Это может быть дорого, если ради одного клиента приходится держать устаревшую интеграцию или вручную запускать ежемесячное задание. Рассчитайте стоимость исполнения обещания до следующего момента принятия решения, затем выберите: сохранить его, пересогласовать с клиентом или включить обязательство в условия сделки. Не убирайте условие молча после закрытия, чтобы потом назвать уход клиента неожиданным.

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

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

Считайте опубликованный план намерением, пока договор не превращает его в обязательство. Оценивайте обещанную работу по артефактам: макетам, незавершенным веткам, разрешениям провайдеров и условиям приемки. Фраза продавца «почти готово» мало значит, если осталось перенести данные, изменить оплату, написать документацию и подготовить поддержку. Готовую проверяемую функцию следует оценивать иначе, чем оптимистичное описание прогресса.

Бизнес-модель определяет бюджет на разработку

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

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

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

Переведите выводы проверки в годовую стоимость владения. Для неопределенной работы используйте диапазоны и явно укажите допущение для каждого. Как минимум включите:

• Задачи продавца, для которых нужно найти нового исполнителя
• Расходы на хостинг и провайдеров при нынешней и ожидаемой нагрузке
• Срочные исправления безопасности и надежности, без которых нельзя продолжать работу
• Обязательства по поддержке, лицензиям, налогам и требованиям регулирования
• Изменения продукта, уже обещанные остающимся клиентам

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

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

Условия передачи требуют проверяемой приемки

Передача работает, когда покупатель способен доказать контроль, а обязанность продавца устранить пробелы ограничена понятными рамками. Обещание «разумной помощи» в течение нескольких недель заставляет обе стороны спорить, чем считать сломанное развертывание: обучением, дефектом или новой работой.

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

Короткий файл приемки может выглядеть так:

asset: production_deployment
buyer_owner: [email protected]
seller_access: temporary_named_user
acceptance:
  - buyer deploys reviewed commit to staging
  - buyer promotes release to production
  - buyer rolls back release
evidence:
  - pipeline run identifiers
  - deployed commit identifier
  - rollback timestamp
deadline: before_closing
blocking: true

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

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

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

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

Если продавец отказывается от проверяемых тестов со словами «это совсем маленький продукт», уменьшайте сложность покупки, но не объем подтверждений. Маленькие системы проще проверять. Концентрация владения делает проверки нужнее.

Первый месяц должен сокращать неизвестность

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

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

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

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

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

Некоторые сделки нужно остановить до закрытия

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

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

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

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

Если у покупателя нет опытного технического руководителя, Team & AI Audit от oleg.is может за пять рабочих дней превратить репозиторий, рабочие процессы и допущения о команде в оценку расходов и риска до крупной перестройки. Привлекаете ли вы внешнюю помощь или своего инженера, требуйте подтверждения, связанного с приемкой. Сделка становится управляемой, когда у каждой существенной зависимости есть владелец, проверка и последствие.