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

Проблема, а не назва блокчейну

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

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

Чому Solana

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

Докази продуктового попиту

Кількість підписників, учасників Discord або заявок на allowlist не дорівнює попиту. Для раннього продукту корисніші перевірювані сигнали:

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

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

Команда і розподіл відповідальності

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

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

Фінансування, токен і конфлікти інтересів

Якщо проєкт має токен або планує його випуск, інтерв’ю повинно охопити розподіл, строки розблокування, права інвесторів, контроль казначейства та користь токена, яку не можна замінити звичайною оплатою. Не варто називати продаж токена «доходом продукту»: це різні економічні явища.

Питання про фінансування мають бути прямими:

  1. На скільки місяців вистачить коштів за поточного рівня витрат?
  2. Яка частина бюджету залежить від курсу SOL або іншого активу?
  3. Хто контролює казначейство і як фіксуються рішення?
  4. Чи є зобов’язання перед грантодавцями або інвесторами?
  5. Які метрики команда не буде штучно стимулювати токенами?

Безпека і відповідальність перед користувачами

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

Юридичний контекст

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

Таблиця перевірки відповідей

ТемаЩо можна перевіритиСлабка відповідь
ПопитКогортні метрики, записи досліджень, повторне використанняЛише кількість підписників
ТехнологіяАрхітектура, транзакції, репозиторій, аудит«Solana швидка й дешева»
ФінансиRunway, бюджет, контроль казначействаОбіцянки майбутньої ціни токена
БезпекаМодель загроз, тестування, план реагуванняПосилання лише на бренд аудитора
КомандаРолі, резервування, процес рішеньУсе тримається на одній людині

Підсумок

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

Джерела