Рік потому: як повторно оцінювати продукт і його обіцянки

Уявіть умовний проєкт, який на етапі запуску обіцяв «інфраструктуру для масових мікроплатежів із пропускною здатністю мільйон транзакцій на добу за мінімальну комісію». Це конкретна метрика — її можна зафіксувати. Рік потому репозиторій отримує кілька комітів на місяць, останній оновлений whitepaper датується тим самим роком, а реальна пропускна здатність, якщо її вдається виміряти через публічні інструменти, виявляється на порядки меншою за заявлену. Зовнішні умови могли змінитися — можливо, мережа зазнала масштабних оновлень, можливо, з’явилися нові технічні обмеження. Можливо, команда переглянула пріоритети. Помилка — не в тому, що метрика не досягнута, а в тому, що про це ніхто не сказав відкрито. Наслідок — втрата довіри, яку можна було б зберегти чесною комунікацією. Урок для інших команд: якщо ви змінюєте цілі, скажіть про це прямо — це не слабкість, це базова надійність.

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

Кластер «Рік потому» — частина розділу Після хайпу, де ми системно повертаємося до запущених продуктів і наративів екосистеми Solana.

Що охоплює цей кластер

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

• Продукт. Чи працює те, що було обіцяно? Чи доступний код, інтерфейс, інфраструктура? Які функції реалізовані, а які залишилися на папері? Цей вимір найбільш об’єктивний, бо його можна перевірити без залежності від слів команди.
• Користувачі. Чи є активність після завершення стимулів — ейрдроп-ів, грантів, майнінг ліквідності? Як відрізнити органічне використання від штучно роздутого? Це найскладніший вимір, бо в екосистемі Solana значна частина активності історично спирається на стимули.
• Команда й модель. Хто зараз керує проєктом? Чи змінилася дорожня карта, і якщо так — чи були ці зміни пояснені? Чи змінився спосіб заробітку порівняно з початковим? Тут важливо фіксувати сам факт зміни, а не лише оцінювати її.
• Темп розвитку. Повільний розвиток може бути нормою для складної інфраструктури — протоколи нижчих рівнів часто розвиваються місяцями без видимих релізів. Але є різниця між тихою роботою і фактичною зупинкою.

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

На що тут є відповіді

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

• Що саме було обіцяно? Не загальний наратив типу «ми змінимо DeFi», а конкретні метрики, функції, терміни. Чи зафіксовані вони в датованих анонсах, архівних версіях сторінок, whitepaper або офіційній документації? Якщо сторінка змінена — чи є архівна копія, яка підтверджує початкову обіцянку?
• Що можна перевірити зараз без залежності від слів команди? Чи працює продукт? Чи доступний код у репозиторії? Чи є транзакції в мережі, які можна побачити через блокчейн-експлорер? Чи відповідають API-ендпоінти?
• Що сталося після завершення стимулів? Якщо ріст активності спирався на зовнішні стимули, що залишилося, коли вони закінчилися? Яка частка користувачів повернулася без стимулу? Чи взагалі можна це виміряти?
• Хто зараз у команді? Чи ті самі люди, що анонсували проєкт? Чи були ключові зміни, і якщо так — чи були вони комуніковані? Вихід одного інженера — це нормальна ротація. Тихий перехід усієї команди до іншого проєкту — це інший сигнал.
• Чи змінилася бізнес-модель? Те, як проєкт заробляє або планує заробляти на етапі запуску і через рік — це часто два різні сценарії. Важливо фіксувати сам факт зміни і розуміти мотиви, а не лише констатувати розбіжність.
• Повільний розвиток чи зупинка? Відсутність гучних релізів не означає відсутність роботи. Але є об’єктивні критерії — коміти в репозиторії, оновлення залежностей, відповіді на issue, зміни в документації — які допомагають розрізнити ці стани.

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

Перші матеріали для входу

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

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

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

Що читати далі

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

• Рік потому: як перевірити, чи залишилися користувачі після завершення стимулів — фокус на розрізненні органічної активності від штучно роздутої. Які метрики дивляться, які джерела даних використовують, де межа між нормальним відтоком користувачів після завершення кампанії і колапсом активності, який свідчить про відсутність product-market fit. Окремо розглядається питання: чи можна взагалі достовірно виміряти цей показник у децентралізованому середовищі.
• Рік потому: як перевірити зміни команди, дорожньої карти й бізнес-моделі — що робити, коли ключові люди пішли без публічного пояснення; коли roadmap замінили новим документом без згадки про попередній; коли спосіб монетизації змінився настільки, що суперечить початковим обіцянкам. Критерії для оцінки кожної з цих змін окремо, а також межа між нормальною адаптацією й підміною суті проєкту.
• Рік потому: коли повільний розвиток є нормою, а коли це ознака зупинки — як не прийняти відсутність прогресу за «стратегічну паузу» і як не визнати мовчання смертю проєкту, коли за ним є реальна робота. Об’єктивні критерії — коміти, оновлення залежностей, відповіді на issue, зміни в документації — і їхні обмеження. Окремий фокус на тому, що різні типи проєктів мають різні нормальні темпи: інфраструктурний протокол і consumer-dapp живуть за різними ритмами.

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

Як підтримувати актуальність

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

• Датовані анонси та архівні версії сторінок. Обіцянки потрібно фіксувати в моменті. Якщо оригінальна сторінка змінена, шукайте архівну копію — без неї порівняння неможливе, і будь-який висновок буде базуватися на припущеннях.
• Репозиторії та історія комітів. Для проєктів з відкритим кодом це один із найбільш об’єктивних сигналів активності. Але є нюанси: рутинні оновлення залежностей не те саме, що розробка нового функціоналу, а закритий код не означає відсутність роботи — він лише ускладнює незалежну перевірку.
• Поточний статус продукту. Чи працює інтерфейс? Чи доступні API-ендпоінти? Чи є транзакції в мережі? Ці речі можна перевірити без залежності від заяв команди, і саме тому вони є найбільш надійною основою для висновків.
• Відповіді команди. Якщо команда публічно відповідає на питання про зміни — це вже інформація, навіть якщо відповіді незадовільні. Мовчання — теж сигнал, але його інтерпретація потребує обережності: іноді за мовчанням стоїть юридична обережність або NDA, а не відсутність роботи.
• Незалежні дані. Блокчейн-експлорери, аналітичні платформи, відкриті дашборди — усе, що не контролюється самою командою проєкту. Але й тут важливо розуміти методологію збору даних платформою, яку ви використовуєте: різні інструменти можуть показувати різні цифри для одного й того ж проєкту.

Обмеження підходу

Цей кластер не дає універсальної формули «живий чи мертвий». Є проєкти, які формально відповідають усім критеріям активності — коміти є, інтерфейс працює, транзакції проходять — але фактично не приносять користі нікому, крім власної команди. І навпаки — є продукти з мінімальним публічним слідом, які вирішують реальне завдання для вузької аудиторії й роблять це стабільно.

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

Редакція солана.укр