Рік потому: як перевірити зміни команди, дорожньої карти й бізнес-моделі

Фокус перевірки без маркетингового шуму

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

Межа аналізу чітка: ми розглядаємо саме інструментарій перевірки, а не те, чи варто довіряти крипторинку загалом. Ми також не торкаємося того, чи залишилися користувачі після завершення стимулів — це окрема тема, яку детально розкрито в окремому матеріалі кластера.

Що відбувається під капотом

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

Методика спокійного постмортему складається з трьох паралельних ліній перевірки.

Команда: хто пішов, хто прийшов, хто залишився

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

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

Дорожня карта: що прибрали, що додали, що переформулювали

Дорожня карта — найгнучкіший інструмент маркетингу в крипті, тому її перевірка потребує найбільшої уважності. Алгоритм такий:

1. Фіксація оригіналу. Зберегти або знайти архівну версію карти на момент запуску. Без цього будь-яке порівняння неможливе.
2. Покрокове зіставлення. Кожен пункт оригіналу позначити одним із трьох статусів: реалізовано, прибрано без реалізації, переформульовано.
3. Аналіз замін. Якщо замість трьох технічних функцій з’явилися три партнерські інтеграції — це не «виконання карти», а зміна напрямку.

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

Бізнес-модель: звідки реально надходять гроші

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

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

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

Де факти, а де інтерпретація

Щоб перевірка була коректною, потрібні конкретні класи джерел, а не настрої в Twitter.

Що перевіряєте	Де шукати оригінал	Де шукати поточний стан
Склад команди	Архівні версії сайту, первинні анонси, профілі на момент запуску	Поточний сайт, репозиторії (коміти), активні акаунти
Дорожня карта	Архівні копії сторінки roadmap, лонгріди-анонси, презентації	Поточна версія карти, реліз-нотатки, актуальний функціонал
Бізнес-модель	Оригінальний whitepaper, документація, інтерв’ю на старті	Смарт-контракти, звіти, наявні механізми монетизації

Позиція команди завжди буде оптимістичнішою за реальність — це закономірно. Позиція критиків — навпаки. Завдання перевірки не в тому, щоб обрати чиюсь сторону, а в тому, щоб побудувати незалежну лінію від точки А до точки Б.

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

Компроміси й невизначеність

Будь-яка методика має обмеження, і чесно їх визнати — частина аналізу.

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

Ризик помилкового негативного висновку. Проєкт може змінити половину команди, переписати карту й змінити модель — і при цьому стати кращим продуктом. Тому головна помилка аналізу «рік потому» — це автоматичне прирівнювання зміни до деградації. Методика показує що змінилося, а не наскільки це погано.

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

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

Що з цього випливає

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

Що інші команди можуть перевірити у себе вже зараз:

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

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

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

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