2 хв читанняDue diligenceАудит кодуІнвесторам

Технічний due diligence: десять запитань перед інвестицією

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

KBЗасновник і CTO

У типовій угоді продукт показують на демо, ринок — у моделі, команду — на співбесідах. Софту, який має витягнути наступні два роки зростання, часто дістається одне запитання — «технічно все надійно?» — і впевнене «так». Технічний due diligence існує тому, що це «так» щире і часто хибне: не через нечесність, а тому, що засновники рідко бачать власну систему ззовні.

Запитання нижче не вимагають читати код. Їх ставлять команді засновників і звіряють із доказами: репозиторієм, дашбордом, рахунком. Розмиті чи суперечливі відповіді — це і є висновок.

Власність і контроль

  • Кому належать код, домен, хмарні акаунти й сторінки в магазинах застосунків — компанії чи особисто засновнику або підряднику?
  • Чи зможе компанія завтра задеплоїти продукт, якщо двоє найдосвідченіших інженерів підуть?

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

Поставка

  • Як часто код потрапляє в продакшен і як — через пайплайн чи хтось вручну запускає команди?
  • Коли реліз щось ламає, як його відкочують і коли це було востаннє?
  • Чи є staging-середовище, достатньо схоже на продакшен, щоб йому довіряти?

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

Надійність і дані

  • Чи є резервні копії продакшен-даних і чи хтось колись із них відновлювався?
  • Що сталося під час останньої аварії і як команда про неї дізналася?
  • Які персональні чи регульовані дані зберігає продукт і хто має до них доступ?

Вартість, масштаб і план

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

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

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

Як читати відповіді

Мало хто на етапі seed чи Series A добре відповідає на всі десять — і не повинен. Важливо, чи команда знає свої слабкі місця і чи має реалістичний, оцінений у грошах план. Засновник, який каже «деплой у нас ручний, і ось коли ми це виправимо», — краща ставка, ніж той, у кого все гаразд. Незалежний огляд потрібен, щоб відрізнити одного від іншого до переказу грошей, а не після.

Дотичні послуги