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

solana.org.ua — незалежний український освітній хаб. Ми не є офіційним представництвом Solana Foundation чи Solana Labs і не організовуємо хакатони. Усі конкретні дати, правила та призові фонди треба перевіряти на сайтах організаторів відповідних подій.

Передумови та цільова аудиторія

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

Мінімальні передумови для старту:

  • Базове розуміння моделі обліку Solana (рахунки, PDA — Program Derived Address, транзакції)
  • Навички написання простих смарт-контрактів на Anchor або хоча б на Rust без фреймворку
  • Досвід роботи з CLI-інструментами (Solana CLI, Anchor CLI) та розгортання програм у devnet
  • Розуміння принципів взаємодії фронтенду з блокчейном через RPC-вузли (RPC — Remote Procedure Call)

Цільова аудиторія:

  • Розробники (backend на Rust/Anchor, фронтенд на React/Next.js або аналогах), які вперше або повторно йдуть на хакатон
  • Дизайнери продуктів, що працюють у Web3 і хочуть зрозуміти, як їхня робота впливає на результат хакатону
  • Продакт-менеджери та фаундери, які планують використати хакатон як валідацію ідеї перед повноцінним запуском (але без перетину з матеріалом Стартап на Solana: маршрут, де розглядається довгострокова побудова бізнесу)

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

Етап 1 — вибір хакатону та формування команди

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

Критерії вибору хакатону

  • Тематика треків. Чи збігається хоча б один трек з вашою експертизою або ідеєю, яку ви хочете протестувати. Універсальні хакатони без чітких треків часто призводять до розмитих проєктів.
  • Формат і тривалість. Онлайн, офлайн чи гібрид. Хакатони на 24 години вимагають іншого підходу до скоупу, ніж тижневі.
  • Склад журі та критерії оцінювання. Перевірте, чи опубліковані критерії заздалегідь. Якщо журі складається переважно з інвесторів — акцент має бути на ринковій валідації. Якщо з інженерів — на технічній якості.
  • Вимоги до ліцензування та IP. Деякі хакатони вимагають відкритого вихідного коду, інші залишають права за командою. Це впливає на те, чи зможете ви після події продовжити розробку як закритого продукту.

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

Формування команди

Оптимальний розмір команди для хакатону на Solana — від 3 до 5 людей. Менше — важко покрити всі необхідні компетенції. Більше — зростають комунікаційні витрати.

Ключові ролі:

  • Smart-contract розробник (1–2 особи). Відповідає за написання програм на Anchor/Rust, роботу з PDA, обробку помилок та безпеку.
  • Фронтенд-розробник (1 особа). Інтеграція з гаманцями (Phantom, Solflare), виклик інструкцій через RPC, відображення даних.
  • Дизайнер/продукт (1 особа). Фокусується на користувацькому досвіді, презентації та розповіді про проєкт. На хакатонах візуальна подача часто вирішує при рівній технічній якості.

Що перевірити перед фіналізацією команди:

  • Чи є у всіх учасників стабільний доступ до середовища розробки протягом всього хакатону
  • Чи узгоджені часові зони та графік доступності (особливо для онлайн-форматів)
  • Чи є спільне розуміння мінімально життєздатного проєкту (MVP) до старту

Етап 2 — підготовка проєкту та технічний стек

Хакатон виграється не на етапі написання коду, а на етапі визначення того, що саме ви будете писати.

Визначення скоупу

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

Алгоритм визначення скоупу:

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

Технічний стек для хакатону на Solana

Хакатон — не час для експериментів із незнайомими інструментами. Використовуйте те, що ви знаєте, або що має мінімальний поріг входу.

Шар Рекомендовані інструменти Коментар
Смарт-контракти Anchor Значно скорочує шаблонний код порівняно з чистим Rust. Для хакатону це критично.
Локальне середовище Solana Test Validator Запускається локально, не залежить від доступності devnet. Обов'язково налаштуйте до старту.
Фронтенд React/Next.js + @solana/web3.js або @solana/spl-token Вибір залежить від вашого досвіду. Головне — щоб ви вміли підключати гаманець і відправляти транзакції.
Інтеграція з гаманцями @solana/wallet-adapter Стандартний спосіб підключення Phantom, Solflare та інших гаманців.
RPC Публічні endpoints devnet або власний Для хакатону зазвичай достатньо публічних, але мати запасний — розумна пересторога.

Підготовка до старту

Те, що можна зробити до офіційного старту хакатону (якщо правила дозволяють):

  • Ініціалізувати репозиторій, налаштувати CI/CD, структуру проєкту
  • Підготувати локальне середовище: перевірити роботу Solana Test Validator, розгортання тестової програми
  • Створити заготовки фронтенду: роутинг, підключення гаманця, базові компоненти
  • Підготувати шаблон розгортання програми на devnet (скрипт, який ви точно тестували)

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

Етап 3 — подача, презентація та оцінювання

Навіть найкращий технічний проєкт програє, якщо його не вдалося подати й презентувати.

Подача проєкту

Уважно прочитайте вимоги до подачі. Зазвичай це включає:

  • Вихідний код. Відкритий репозиторій з читабельним README, інструкцією зі збірки та розгортання. Журі не буде гадати, як запустити ваш проєкт.
  • Робочий демо-доступ. Розгорнутий фронтенд (часто на Vercel, Netlify або аналогах) + розгорнута програма на devnet. Перевірте, що демо працює самостійно, без локальних залежностей.
  • Відеопрезентація. Якщо вимагається — зніміть її завчасно, не в останню годину. Формат зазвичай: проблема → рішення → демо → технічні деталі → наступні кроки.
  • Текстова заявка. Короткий опис, що відповідає на питання: що зроблено, яку проблему вирішено, чому саме на Solana.

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

Презентація перед журі

Якщо хакатон передбачає живий пітчинг:

  • Починайте з проблеми, а не з технології. Журі чує десятки презентацій, що починаються з «ми використовуємо Solana».
  • Покажіть демо якомога раніше. Ідеально — у перші 30 секунд після формулювання проблеми.
  • Говоріть про обмеження чесно. Журі цінує розуміння меж проєкту більше, ніж завищені обіцянки.
  • Підготуйтеся до питань про безпеку: як ви обробляєте помилки транзакцій, чи є перевірки на переповнення, як працює авторизація через PDA.

Як зазвичай оцінюють

Хоча критерії залежать від організатора, типова структура ваги:

  • Технічна реалізація та якість коду. Чи працює проєкт стабільно, чи продумана обробка помилок, чи розумно використовуються можливості Solana (композуваність через CPI — Cross-Program Invocation, ефективність транзакцій).
  • Продуктове мислення. Чи зрозуміла проблема, чи є реальна цільова аудиторія, чи продуманий користувацький досвід.
  • Інноваційність. Чи пропонує проєкт щось нове, чи це чергова форк-версія існуючого рішення.
  • Використання екосистеми. Чи застосовані специфічні для Solana можливості, чи проєкт можна було б реалізувати на будь-якому іншому блокчейні без змін.
  • Можливість продовження. Чи виглядає проєкт як щось, що має сенс розвивати після хакатону.

Наступні кроки після хакатону

Хакатон закінчився, але цінність проєкту не обов'язково зникає разом із ним.

Якщо проєкт отримав приз або позитивний відгук:

  • Зафіксуйте зворотний зв'язок від журі та учасників — це найцінніша валідація, яку важко отримати іншим шляхом
  • Оцініть, чи є сенс перетворювати хакатонний прототип на повноцінний продукт. Для цього варто перейти до матеріалу Стартап на Solana: маршрут, де розглядається системний підхід до побудови проєкту
  • Виправте критичні технічні проблеми, виявлені під час хакатону, перш ніж показувати проєкт інвесторам або користувачам

Якщо результат нижчий за очікування:

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

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

Джерела