Відсутність призового місця на хакатоні не означає, що проєкт варто закрити. Більшість продуктів, які зараз працюють у Solana-екосистемі, не перемагали на перших хакатонах — вони продовжували розробку, знаходили користувачів і отримували фінансування пізніше. Нижче — конкретні кроки, щоб перевірити, чи варто рухатися далі, і як це зробити без зайвих витрат часу.
Чи має сенс продовжувати без призового місця
Перемога на хакатоні — це валідація від журі, а не від ринку. Журі оцінює за фіксованими критеріями: технічна складність, інноваційність, відповідність темі. Реальні користувачі оцінюють інше: чи вирішує продукт їхню проблему, чи зручно ним користуватися, чи є сенс повертатися.
Продовжувати має сенс, якщо виконується хоча б одна умова:
- Під час хакатону надійшли запити від людей, які хочуть скористатися продуктом, а не просто поставити «зірочку» у Discord.
- Ви самі б користувалися цим інструментом у повсякденній роботі з Solana — продукт вирішує вашу реальну завдання.
- Технічна архітектура виявилася робочою, і ви бачите шляхи масштабування без повного переписування.
- Проєкт займає вузьку нішу, де конкуренція мінімальна, але проблема існує.
Не продовжувати, якщо:
- Ідея народилася виключно під критерії хакатону, і ви не бачите застосування поза цим контекстом.
- Команда розпалася одразу після події, і ви залишилися соло з кодом, який не повністю розумієте.
- Продукт дублює існуючий рішення без явної переваги в швидкості, вартості чи UX.
Як оцінити, чи є реальний попит на проєкт
Не варто покладатися на інтуїцію чи захоплення команди. Використовуйте конкретні сигнали, які можна перевірити за кілька днів.
Кількісні сигнали:
- Кількість унікальних гаманців, які взаємодіяли з вашим контрактом під час або після хакатону. Навіть 5–10 реальних транзакцій краще за нуль.
- Збільшення відвідуваннь демо-сторінки після публікації результатів хакатону, якщо вона залишилася доступною.
- Кількість запитів у RPC-ноду вашого проєкту, якщо ви розгорнули власну інфраструктуру.
Якісні сигнали:
- Конкретні пропозиції від потенційних користувачів: « мені б це допомогло, якби воно вміло X» — це набагато цінніше за «круто, лайк».
- Запити від інших команд або проєктів щодо інтеграції вашого рішення через API або CPI (Cross-Program Invocation — виклик однією програмою на Solana іншої програми).
- Питання від менторів або суддів поза формальною оцінкою, де вони цікавляться технічними деталями реалізації, а не просто зауваженнями до pitch-деки.
Швидкий тест: опублікуйте короткий пост у тематичному каналі з описом проблеми, яку вирішує проєкт, і запитайте, чи стикаються люди з цим. Не рекламуйте продукт — рекламуйте проблему. Якщо відповідей немає, попиту, найімовірніше, немає.
Мінімальні кроки для підтримки проєкту
Мета цього етапу — не випускати повноцінний продукт, а утримати проєкт у робочому стані мінімальними зусиллями. Це дозволить повернутися до розробки, коли з'являться ресурси або підтвердження попиту.
Виправлення критичних багів
Пріоритет — ті помилки, які не дозволяють новому користувачу виконати базовий сценарій. Якщо при розгортанні смарт-контракту на devnet виникає помилка транзакції — це критичний баг. Якщо не відображається іконка в темному режимі — ні.
Чек-лист для перевірки:
- Контракт деплоїться на devnet без помилок.
- Базовий сценарій (наприклад, створення облікового запису через PDA, виконання транзакції, читання даних) проходить від початку до кінця.
- Фронтенд підключається до контракту і коректно відображає стан.
Якщо після хакатону ви не можете відтворити робочий стан на devnet протягом 30 хвилин — зафіксуйте поточний код у гілці репозиторію з тегом «post-hackathon» і задокументуйте, що саме не працює. Це дозволить повернутися пізніше без розгубленості.
Додавання відсутнього функціоналу
На хакатоні часто залишають «заглушки» — функції, які показані в демо, але не реалізовані в коді. Визначте, які з них критичні для першого реального користувача, і реалізуйте лише їх.
Критерій відбору: якщо без цієї функції користувач не зможе виконати жодного корисного дії — реалізуйте. Якщо це «приємний доповнення» — залиште на потім.
Типові приклади «заглушок» на хакатонах:
- Автентифікація через гаманець працює, але немає збереження сесії — користувач логінитися при кожному перезавантаженні сторінки.
- Транзакція відправляється, але статус не оновлюється автоматично — треба оновити сторінку вручну.
- Дані зберігаються в контракті, але немає інтерфейсу для їхнього перегляду.
Збір перших користувацьких відгуків
Не чекайте, поки продукт буде «достатньо готовим». Запропонуйте поточну версію 3–5 людям із цільової аудиторії. Формат — не анкета, а 15-хвилинна сесія, де ви спостерігаєте, як людина намагається виконати базовий сценарій.
Що фіксувати:
- На якому кроці людина загальмувала або заплуталася.
- Які дії вона очікувала побачити, але не знайшла.
- Чи зрозуміла вона, що відбулося після підтвердження транзакції в гаманці.
Якщо знайти 3–5 людей для тестування неможливо — це сам по собі сигнал про те, що доступ до цільової аудиторії обмежений, і це треба враховувати в плануванні.
Як знайти перших користувачів для хакатонного проєкту
Хакатонний проєкт має одну перевагу: він уже існує у вигляді робочого демо. Це набагато більше, ніж має більшість ідей на стадії концепції. Використовуйте це конкретно.
Тематичні спільноти Solana: опублікуйте не рекламу, а опис вирішеної проблеми та посилання на демо. Формат: «Столкнувся з проблемою X, зробив інструмент, який вирішує її так-то. Шукаю людей, які мають ту саму проблему, щоб перевірити, чи це взагалі потрібно». Цей підхід викликає менше відторгнення, ніж пряма реклама.
Інші команди з того ж хакатону: якщо ваш проєкт вирішує інфраструктурну завдання (інструменти для розробників, аналітика, UX-компоненти), інші команди — ваші прямі потенційні користувачі. Напишіть тим, чий проєкт міг би використати ваше рішення.
Twitter/X та Farcaster: короткий пост із скріншотом реального інтерфейсу (не макета) і описом однієї конкретної проблеми, яку вирішує проєкт. Без гучних заяв про «революцію» — просто факт: ось проблема, ось робоче рішення, ось де спробувати.
Обмеження: не витрачайте час на масову розсилку в DM. Конверсія з холодних повідомлень у криптоспільнотах мінімальна, а репутаційні ризики — максимальні.
Наступний крок: подання на грант
Якщо після мінімальної підтримки проєкту та збору перших відгуків ви бачите, що рух має сенс, наступний логічний крок — подання на грант. Solana Foundation та інші організації в екосистемі надають гранти на різних етапах: від ідеї до працюючого продукту з користувачами.
Що потрібно для подання:
- Робоче демо, доступне для перевірки (devnet або testnet).
- Опис проблеми та того, як проєкт її вирішує — конкретно, без загальних фраз про «децентралізацію».
- Технічна документація: архітектура, використані інструменти (Anchor, Rust, конкретні бібліотеки), розгорнуті контракти.
- План використання коштів з прив'язкою до конкретних етапів розробки, а не загальні суми «на розробку».
- Результати збору відгуків: що ви дізналися від перших користувачів і як це вплине на подальшу розробку.
Перед поданням перевірте актуальні вимоги та дедлайни безпосередньо на офіційному порталі грантів, оскільки вони змінюються між раундами. Не покладайтеся на інформацію з минулих хакатонів або третіх джерел — тільки офіційні джерела.
Грант не компенсує відсутність перемоги на хакатоні — він працює за іншими критеріями. Але хакатонний досвід дає вам те, чого бракує багатьом заявникам: реальний робочий код, розуміння обмежень і конкретний контекст використання.