Хакатон завершився, submission відправлено, результати оголошено. Що далі — залежить не від місця в таблиці, а від того, що ви зробите з проєктом і досвідом наступного дня. Ця сторінка проводить від аналізу поразки чи перемоги через гранти й Demo Day до конкретних кроків: ретроспективи, пошуку ментора, подання на фінансування або фіксації результату в портфоліо.
Чому проєкти програють хакатони
Технічні причини поразки
Найчастіший технічний фактор — проєкт не працює під час демо. Журі не оцінює наміри, воно бачить конкретний запуск. Типові проблеми:
- смарт-контракт деплоїться з помилками, які не були перевірені на devnet-кластері Solana;
- фронтенд не підключається до контракту через некоректно налаштований RPC-ендпоінт;
- транзакції падають через недостатній баланс SOL для комісій або неправильну обробку PDA (Program Derived Address);
- відсутність базової обробки помилок — користувач бачить білий екран замість зрозумілого повідомлення.
Друга група — архітектурні рішення, які не відповідають заявленій проблемі. Наприклад, складна система кросс-chain мостів для завдання, яку можна вирішити одним on-chain контрактом.
Організаційні причини поразки
Техніка працює, але подання не доходить до журі:
- перші дві хвилини pitch-відео витрачені на загальне пояснення блокчейну замість опису самого проєкту;
- немає чіткої відповіді на запитання «хто користувач і чому він це заплатить»;
- розділення ролей у команді не відображено — незрозуміло, хто відповідає за продукт, хто за код, хто за бізнес;
- submission подано в останню годину без перевірки форматування, посилань чи вкладених файлів.
Як проаналізувати власне поразку
Розділіть причини на три категорії: «ми могли виправити до дедлайну», «ми не встигли через планування» і «це було б неможливо за будь-яких умов». Перша категорія — це помилки процесу. Друга — помилки оцінки обсягу. Третя — сигнал, що обрана завдання виходить за межі хакатонного формату.
Наступний крок: що робити далі з проєктом — визначається не місцем у рейтингу, а чесною оцінкою перспектив.
Що робити з проєктом після хакатону
Оцінка перспектив проєкту
Задайте собі три питання:
- Чи є хоча б одна людина поза командою, яка сказала: «Я б це використовувала»?
- Чи вирішує проєкт проблему, яка існуватиме після закінчення хакатону?
- Чи є в команди ресурс (час, навички) зробити наступну ітерацію за два-чотири тижні?
Якщо хоча б на одне питання відповідь «ні» — проєкт, імовірно, залишається хакатонним експериментом. Це нормальний результат для більшості команд.
Три можливі шляхи
- Продовжити розробку. Є сигнал попиту, команда готова працювати далі, є розуміння наступного мінімального кроку.
- Зберегти як навчальний артефакт. Код залишається відкритим, опис фіксується в портфоліо, але активної розробки немає.
- Закрити. Проєкт не витримує перевірки на перспективність, але висновки команди фіксуються через ретроспективу.
Як прийняти рішення про подальшу долю проєкту
Не приймайте рішення в день оголошення результатів. Дайте собі 48–72 години. Після цього проведіть коротку зустріч команди: кожен учасник голосує «продовжити», «зберегти» або «закрити». Якщо є розбіжність — обговоріть, чи готові ті, хто за продовження, працювати без тих, хто проти.
Наступний крок: отримання зворотного зв'язку від журі дасть додаткові дані для цього рішення.
Як отримати зворотний зв'язок від журі хакатону
Де та коли з'являється фідбек від журі
Залежить від формату хакатону. Деякі платформи надають письмові коментарі автоматично після оголошення результатів. Інші — лише за прямим запитом учасника через Discord-канал або email організаторів. Перевірте правила конкретного хакатону: якщо фідбек не передбачений форматом, його не існує.
Як правильно прочитати та інтерпретувати коментарі
Розділіть фідбек на шари:
- Факти: «Контракт не деплоївся під час демо» — це конкретний сигнал до дії.
- Оцінки: «Слабка продуктова чіткість» — це напрямок для роботи, але без деталей.
- Побажання: «Було б круто додати мобільну версію» — це ідеї, а не обов'язкові виправлення.
Факти — пріоритет. Оцінки — другий пріоритет. Побажання — фіксуйте, але не змінюйте через них roadmap.
Які запитання поставити журі, якщо є можливість
- «Який один елемент проєкту ви вважаєте найслабшим?»
- «Чи бачите ви реальну аудиторію для цього продукту в поточному вигляді?»
- «Що б ви змінили за тиждень до фінального подання?»
Уникайте запитань «чому ми не перемогли» — вони не дають конструктивної інформації.
Як відрізнити конструктивну критику від загальних зауважень
Конструктивна критика вказує на конкретний елемент і містить напрямок виправлення: «Pitch не пояснював, чому саме Solana, а не інший L1». Загальне зауваження звучить як «потрібно більше проробити продукт» — це корисно як сигнал, але не як інструкція.
Наступний крок: на основі фідбеку приймається рішення про продовження або закриття.
Як продовжити розробку проєкту без перемоги
Чи має сенс продовжувати без призового місця
Так, якщо є незалежне від хакатону підтвердження попиту. Перемога в хакатоні — це валідація від журі, а не від ринку. Відсутність призу не означає відсутність користувачів. Навпаки, проєкти, що знайшли перших користувачів поза хакатонним контекстом, мають вищі шанси на грант чи акселерацію.
Як оцінити, чи є реальний попит на проєкт
- Скільки людей залишили контакти з проханням повідомити про запуск?
- Чи є запити в спільнотах (Discord, Twitter, форуми) на рішення саме цієї проблеми?
- Чи готовий хтось тестувати навіть сирі версії?
Навіть 3–5 людей, які готові тестувати, — це кращий сигнал, ніж третє місце в хакатоні без жодного зацікавленого користувача.
Мінімальні кроки для підтримки проєкту
- Виправити критичні баги, виявлені під час демо.
- Опублікувати репозиторій з README, що пояснює, як запустити проєкт локально.
- Написати один пост з описом проблеми, рішення та статусу — без перебільшень.
Це займає 2–3 дні й підтримує проєкт у стані, придатному для подання на грант.
Як знайти перших користувачів для хакатонного проєкту
Шукайте не «користувачів взагалі», а людей, які вже скаржаться на проблему, яку ви вирішуєте. Тематичні Discord-сервери, підфоруми на Reddit, треди в Twitter — місця, де люди описують біль. Звертайтеся з конкретним запитом: «Ми зробили прототип для X, шукаємо 5 людей для тестування на devnet. Є 15 хвилин?»
Наступний крок: зібравши перші свідчення попиту, можна подаватися на грант.
Як використати хакатонний досвід для портфоліо
Що саме варто включити в портфоліо
- Назва проєкту, хакатон, дата та роль у команді.
- Опис проблеми та вашого конкретного внеску (код, дизайн, продуктова логіка, дослідження).
- Посилання на репозиторій, демо або запис pitch-відео.
- Один конкретний технічний виклик і як ви його вирішили.
Не описуйте весь проєкт — описуйте свій внесок. Рецензент портфоліо має бачити, що саме ви вмієте.
Як презентувати хакатонний досвід у резюме
Уникайте формулювання «брав участь у хакатоні». Замість цього: «Розробив смарт-контракт на Anchor для DeFi-прототипу в межах хакатону на Solana. Команда з 4 осіб, 48 годин, фінальне подання — топ-20 із 120 команд». Конкретні числа й технології працюють краще за описи.
Як використати хакатон для нетворкінгу
Протягом тижня після хакатону напишіть учасникам інших команд, чий проєкт вам сподобався. Не з проханням, а з конкретним коментарем: «Ваш підхід до X був цікавий, ми робили схожу річ інакше — ось як». Це відкриває діалог без тиску. Також напишіть менторам, якщо вони давали корисні поради — з коротким описом того, що ви реалізували з їхньою рекомендацією.
Наступний крок: якщо проєкт продовжується — підготовка до Demo Day.
Що таке Demo Day на Solana
Формат та мета Demo Day
Demo Day — це окрема подія, де обрані команди презентують свої проєкти перед інвесторами, менторами та партнерами екосистеми Solana. На відміну від хакатонного подання, мета Demo Day — не перемога в конкурсі, а залучення уваги для наступного етапу: фінансування, акселерації, партнерства.
Як команди потрапляють на Demo Day
Механізм відбору залежить від організатора. Деякі Demo Day є прямим продовженням хакатону — туди запрошують призерів та фіналістів. Інші — окремий процес із власною заявкою. Перевірте правила конкретної події: якщо не знайшли інформацію про відбір, зверніться до організаторів безпосередньо.
Чим Demo Day відрізняється від фінального подання на хакатоні
| Критерій | Хакатонне подання | Demo Day |
|---|---|---|
| Аудиторія | Журі хакатону | Інвестори, партнери, потенційні клієнти |
| Фокус pitch-у | Технічна реалізація + ідея | Бізнес-модель, traction, команда |
| Час | Зазвичай 3–5 хвилин | 5–10 хвилин + сесія Q&A |
| Очікуваний результат | Призове місце | Фollow-up зустрічі, інтерес до фінансування |
Хто присутній: інвестори, ментори, партнери екосистеми
Склад аудиторії варіюється, але зазвичай це представники фондів, що інвестують у Solana-проєкти, технічні ліди екосистемних команд та оператори грантових програм. Вони приходять не оцінювати, а шукати — тому ваша завдання дати їм причину підійти після виступу.
Наступний крок: підготовка виступу для Demo Day вимагає іншого підходу, ніж хакатонний pitch.
Як податися на грант після хакатону
Які грантові програми існують в екосистемі Solana
Грантова інфраструктура змінюється: програми запускаються, призупиняються або оновлюють умови. Перевірте актуальний перелік на офіційних ресурсах екосистеми Solana. Типові категорії: гранти на розробку інфраструктури, гранти на інструменти для розробників, гранти на ком'юніті-проєкти та гранти на конкретні вертикалі (DeFi, NFT, RWA — токенізація реальних активів).
Вимоги до грантової заявки
- Опис проблеми та рішення — чітко, без загальних фраз про «децентралізацію всього».
- Технічна архітектура — що саме працює на Solana, які програми використовуються (Anchor, Seahorse тощо).
- Розподіл бюджету — на що саме підуть кошти, з прив'язкою до етапів.
- Дорожня карта — конкретні мілістоуни з термінами, а не «Q1 — розробка, Q2 — запуск».
- Команда — хто робить, який досвід, скільки часу готові присвятити.
Як адаптувати хакатонний submission під грантову заявку
Хакатонний submission фокусується на тому, що зроблено за 48 годин. Грантова заявка — на тому, що буде зроблено за 3–6 місяців. Конкретні кроки адаптації:
- Замініть «ми зробили прототип» на «ми валідували гіпотезу через прототип і тепер плануємо…».
- Додайте розділ про попит: скільки людей проявили інтерес, який фідбек отримано.
- Опишіть ризики та як їх пом'якшити — грантові комітети це очікують.
- Видаліть хакатонний контекст («за 48 годин наша команда…») — він не додає ваги грантовій заявці.
Типові причини відмови у гранті
- Проєкт не пояснює, чому саме Solana — якщо те саме можна зробити на будь-якому L1, комітет запитає, чому виділяти кошти саме вам.
- Бюджет не прив'язаний до конкретних результатів — «50 000 доларів на розробку» без розбивки по етапах.
- Відсутність технічної деталізації — заявка виглядає як ідея, а не як план реалізації.
- Команда не має релевантного досвіду або не демонструє готовність витрачати час.
Наступний крок: якщо грант не підходить або проєкт потребує більшої підтримки — розглядайте акселераційні програми.
Як потрапити до акселераційної програми після хакатону
Які акселераційні програми працюють із Solana-проєктами
Перелік програм змінюється. Перевірте актуальну інформацію на офіційних каналах екосистеми Solana та платформ, що агрегують акселераційні програми для Web3-проєктів. Деякі програми фокусуються на ранніх стадіях (pre-seed), інші — на проєктах із готовим продуктом і першими користувачами.
Що очікують акселератори від команди
- Повна відданість. Акселерація — це не паралельний проєкт. Команда має бути готова працювати над ним повний робочий день.
- Валідація. Наявність користувачів, навіть кількох, значно підвищує шанси.
- Розуміння метрики. Що ви вимірюєте і як дізнаєтеся, що проєкт рухається в правильному напрямку.
- Готовність до змін. Акселератори шукають команди, які можуть змінити напрямок на основі фідбеку, а не ті, що вперлися в початкову ідею.
Як підготувати заявку на акселерацію
Заявка на акселерацію ближча до інвестиційного pitch-деку, ніж до технічного опису. Фокусуйтеся на: проблемі, ринку, команді, traction (навіть мінімальному) та тому, чому саме зараз. Технічна архітектура важлива, але вона — підтвердження здатності реалізувати, а не головний аргумент.
Чим акселерація відрізняється від гранту
| Критерій | Грант | Акселерація |
|---|---|---|
| Формат підтримки | Фінансова, зазвичай без еквіті | Фінансова + менторство + нетворкінг, часто з еквіті |
| Тривалість | Проєктна (до завершення етапу) | Фіксована програма (6–12 тижнів) |
| Очікування | Доставка заявленого результату | Підготовка до раунду фінансування |
| Підходить для | Проєкти з чітким технічним scope | Команди, що будують повноцінний продукт |
Довгострокова продуктова стратегія, моделі монетизації та масштабування розглядаються в стартапному розділі сайту.
Наступний крок: незалежно від результатів подань на грант чи акселерацію — проведіть ретроспективу команди.
Як провести ретроспективу команди після хакатону
Формат ретроспективи для хакатонної команди
Виділіть 60–90 хвилин протягом тижня після хакатону. Формат — структурована розмова, а не вільне обговорення. Використовуйте три колонки: «Що спрацювало», «Що не спрацювало», «Що змінити наступного разу». Кожен учасник додає пункти в усі три колонки перед обговоренням.
Що обговорити
- Розподіл ролей: чи були розмиті зони відповідальності?
- Планування: чи реалістичний був scope на початку?
- Комунікація: чи вчасно повідомлялися проблеми (наприклад, блокер у розробці смарт-контракту)?
- Інструменти: чи заважали якісь з них замість того, щоб допомагати?
- Дедлайн: як команда працювала в останні 6 годин — чи був хаос?
Як фіксувати висновки для майбутнього
Створіть спільний документ із трьома розділами: «Процес», «Техніка», «Комунікація». У кожному — не більше 5 пунктів. Формулюйте як дії, а не спостереження: не «ми погано планували», а «на наступному хакатоні фіксувати scope у вигляді чек-листу до початку коду».
Чи варто зберігати команду для наступного хакатону
Зберігайте, якщо: усі учасники хочуть працювати разом, ретроспектива виявила виправні процесні проблеми (а не фундаментальні розбіжності), і є довіра. Не зберігайте «за звичкою» — команда без довіри на наступному хакатоні покаже гірший результат через накопичене роздратування.
Наступний крок: якщо проєкт продовжується — пошук ментора.
Як знайти ментора для проєкту після хакатону
Де шукати менторів у Solana-екосистемі
- Офіційні Discord-сервери екосистеми Solana та окремих протоколів — шукайте канали типу «mentorship», «office-hours», «developer-support».
- Twitter-спільнота — розробники та архітектори, які публічно діляться технічним досвідом, часто відкриті до запитань.
- Хакатонні ментори — якщо під час події хтось давав корисну пораду, це найприродніший контакт для подальшого менторства.
- Програми для розробників від Solana Foundation — перевірте актуальні ініціативи на офіційних ресурсах.
Якого ментора шукати залежно від потреб проєкту
- Технічний ментор — якщо потрібна допомога з архітектурою, оптимізацією, безпекою смарт-контрактів. Шукайте за технічними публікаціями або контриб'юшнами у відкритий код Solana.
- Продуктовий ментор — якщо проблема в валідації, позиціонуванні, визначенні пріоритетів. Шукайте серед людей, які будували продукти в екосистемі.
- Доменний ментор — якщо проєкт у вузькій ніші (наприклад, RWA або GameFi) і потрібне розуміння специфіки ринку.
Не шукайте «універсального ментора» — це рідко працює.
Як скласти перше повідомлення ментору
Три елементи: хто ви, що зробили, що конкретно потрібно. Приклад:
«Привіт, [ім'я]. Я розробник команди [назва проєкту], ми брали участь у [хакатон] і зробили [короткий опис]. Зараз стикаємося з проблемою [конкретна проблема]. Чи могли б ви виділити 20 хвилин на розмову або підказати, куди краще звернутися?»
Без вступів про «величезну повагу», без прохання «стати нашим ментором» з першого повідомлення — це створює зайвий тиск.
Як побудувати ефективне менторство
- Фіксуйте домовленості: формат (зустріч раз на два тижні / асинхронно), тривалість (попередньо 3–6 сесій), фокус.
- Готуйтеся до кожної сесії: надсилайте питання заздалегідь, показуйте прогрес з попередніх рекомендацій.
- Поважайте час ментора: якщо скасували зустріч — пропонуйте альтернативний слот того ж тижня.
- Завершуйте менторство явно: «Дякуємо за N сесій, ми досягли того, що планували. Хочемо закрити формальне менторство, але будемо раді тримати зв'язок».
Наступний крок: з менторською підтримкою ви готові до подання на грант або акселерацію — або до наступного хакатону з сильнішою командою.