Ця сторінка — практичний маршрут від першого коміту до фінального submission. Тут зібрано все, що потрібно знати про планування спринту, обмеження хакатонного MVP, розгортання на Devnet, оформлення репозиторію, запис demo, створення pitch deck та фінальну перевірку подання. Жодної порожньої мотивації — лише конкретні кроки, чек-листи та типові помилки.
Які критерії оцінювання на Solana-хакатонах
Основні категорії оцінювання
Більшість Solana-хакатонів оцінюють подання за кількома стовпами:
- Технічна реалізація — коректність смарт-контрактів, архітектура, безпека, використання специфічних для Solana механізмів (PDA, CPI, accounts model).
- Продуктовість та користь — наскільки рішення вирішує реальну проблему, чи зрозумілий юзкейс, чи є цільова аудиторія.
- Дизайн і досвід користувача — зручність інтерфейсу, наскільки легко новому користувачу зрозуміти, що відбувається.
- Інноваційність — чи пропонує проєкт щось нове для екосистеми Solana, а не просто копіює існуючий продукт.
- Якісність подання — наскільки зрозуміло описано проєкт, чи працює demo, чи оформлений репозиторій.
Як журі зважує критерії між собою
Технічна реалізація зазвичай має найбільшу вагу, але не є єдиним фактором. Проєкт із ідеальним кодом і незрозумілим юзкейсом програє проєкту з робочим MVP, чітким pitch і менш витонченою архітектурою. Журі дивиться на збалансованість: продукт має працювати, бути корисним і бути презентованим гідно.
На що звернути увагу залежно від треку
Якщо хакатон має треки (DeFi, NFT, Gaming, RWA тощо), критерії можуть зміщуватися. На DeFi-треці важливіша безпека транзакцій і розуміння механіки ринку. На Gaming-треці — досвід гравця та продуктивність. Перевірте офіційний пакет першоджерел поточного хакатону: там завжди вказано, як саме оцінюють кожен трек.
Як використати критерії для пріоритезації завдань
На старті спринту розпишіть критерії оцінювання і проти кожного поставте завдання, які на нього впливають. Це допоможе відсіяти «приємні, але непотрібні» фічі на користь того, що реально приносить бали.
Наступний крок: підготовка подання
Зрозумівши критерії, перейдіть до організації командного процесу та планування спринту.
Як організувати щоденні стендапи в хакатонній команді
Формат короткого стендапу (15 хвилин)
Стендап триває рівно 15 хвилин. Кожен учасник говорить не більше двох хвилин. Формат фіксований: що зробив з останнього стендапу, що планує зробити до наступного, що блокує. Без демонстрації коду, без обговорення архітектури — лише факти.
Що повідомляти: що зробив, що планую, що блокує
«Зробив» — конкретний результат: «написав інструкцію для створення PDA-акаунтів, коміт готовий». «Планую» — конкретне завдання: «сьогодні інтегрую CPI-виклик до oracle-контракту». «Блокує» — конкретна проблема: «не можу отримати достатньо SOL на Devnet для тестування кількох транзакцій підряд». Якщо блокерів немає — просто кажіть «без блокерів».
Як вести загальний трекер завдань
Використовуйте єдину дошку (Kanban-формат) з трьома колонками: «To Do», «In Progress», «Done». Кожна завдання — одна картка з одним відповідальним. Не створюйте підзадачі глибше другого рівня: хакатонний трекер має залишатися плоским і читабельним. Оновлюйте статус до стендапу, а не під час нього.
Як вирішувати конфлікти та блокери в команді
Блокер, який не вирішується 24 години, ескалується на весь team call. Конфлікти щодо архітектури чи фіч вирішуються за принципом «хто бере відповідальність за реалізацію — той і вирішує». У хакатоні немає часу на довгі обговорення: якщо домовитися не вдається за 10 хвилин, обирайте простіший варіант.
Інструменти для асинхронної комунікації
Оберіть один канал для загального спілкування та один для технічних питань. Усі важливі рішення фіксуйте текстом у каналі, а не лише голосом. Якщо команда в різних часових поясах, замініть частину стендапів асинхронними текстовими оновленнями у фіксованому форматі.
Наступний крок: дотримання плану спринту
З налагодженою комунікацією перейдіть до розписаного плану на чотири тижні.
План роботи команди на чотири тижні
Тиждень 1: ідея, архітектура, прототип
Перші три дні — фіналізація ідеї та розподіл ролей. Далі — архітектурний документ: які контракти, які акаунти, які CPI-виклики, яка структура фронтенду. До кінця тижня — працюючий прототип хоча б одного ключового шляху: ініціалізація контракту, одна транзакція, відображення результату на фронтенді.
Тиждень 2: розробка ядра та інтеграція з Devnet
Основний розробницький тиждень. Усі смарт-контракти мають бути написані та розгорнуті на Devnet. Фронтенд підключається до реальних контрактів через RPC-ендпоінт Devnet. До кінця тижня користувач має можливість пройти повний цикл: підключити гаманець, виконати транзакцію, побачити результат.
Тиждень 3: поліпшення, тестування, виправлення помилок
Приоритет — стабільність, а не нові фічі. Напишіть базові тести для контрактів (щонайменше happy path). Перевірте edge cases: що станеться, якщо користувач надішле транзакцію двічі, якщо баланс недостатній, якщо акаунт уже ініціалізовано. Фронтенд-команда виправляє UI-баги та оптимізує завантаження.
Тиждень 4: demo, pitch deck, submission
Розробка зупиняється у середу. Четвер — запис технічного demo. П'ятниця — фіналізація pitch deck та опису проєкту. Субота — фінальна перевірка submission. Неділя — буферний день на випадок непередбачених проблем із платформою подань.
Як адаптувати план, якщо команда стартувала пізніше
Якщо ви вступили в хакатон на другому тижні, скоротіть тиждень 1 до двох днів: архітектурний документ замініть на короткий список контрактів і акаунтів у спільному документі. Прототип об'єднайте з розробкою ядра. Тиждень 3 скоротіть: залиште лише критичні тести та виправлення crash-багів. Тиждень 4 не стискуйте — якісне demo і подання вирішують більше, ніж додаткова фіча.
Чек-лист контрольних точок для кожного тижня
- Кінець тижня 1: архітектура зафіксована, прототип одного шляху працює локально.
- Кінець тижня 2: всі контракти на Devnet, фронтенд підключений, повний цикл працює.
- Кінець тижня 3: немає crash-багів, базові тести проходять, edge cases оброблені.
- Кінець тижня 4: demo записано, pitch deck готовий, submission відправлено.
Наступний крок: визначення складу MVP
Зі спринтом визначенося — тепер вирішіть, що саме входитиме до вашого хакатонного MVP.
Що має входити в хакатонний MVP
Ознаки хакатонного MVP проти повноцінного продукту
Хакатонний MVP — це не мінімальний життєздатний продукт у класичному розумінні. Це мінімальний демонстрований прототип: достатньо, щоб журі побачило робочий механізм і зрозуміло юзкейс. Він не має бути готовим до продакшену, не має масштабуватися, не має покривати всі edge cases.
Обов'язкові компоненти
- Щонайменше один смарт-контракт на Solana — розгорнутий на Devnet, з реальними транзакціями.
- Фронтенд, що підключається до гаманця — користувач має авторизуватися через Phantom або інший підтримуваний гаманець.
- Повний цикл однієї ключової дії — від натискання кнопки до зміни стану on-chain та відображення результату.
- Зрозумілий юзкейс — навіть якщо реалізовано лише одну функцію, має бути зрозуміло, для чого вона і хто буде нею користуватися.
Що можна безпечно пропустити
- Реєстрацію та авторизацію користувачів (гаманець замінює аутентифікацію).
- Адмін-панель, налаштування, профілі.
- Мобільну адаптацію (якщо це не gaming-трек із очікуваною мобільною аудиторією).
- Оптимізацію під масове навантаження.
- Другий та наступні юзкейси — один, але робочий, краще за три незавершених.
Приклади мінімальних MVP, які перемагали
DeFi-протокол з єдиною функцією: deposit токена у пул і отримання LP-токена назад. NFT-маркетплейс із можливістю створити один NFT і виставити його на продаж. Gaming-проєкт, де є лише одна ігрова дія (наприклад, кидок кубика) з on-chain визначенням результату. У кожному випадку — один повний цикл, без «залишимо це на потім».
Наступний крок: розгортання на Devnet
Склад MVP визначено — далі технічне розгортання.
Як розгорнути проєкт на Devnet для хакатону
Що таке Devnet і чому він потрібен для хакатону
Devnet — це тестова мережа Solana, яка імітує Mainnet-Beta за архітектурою, але використовує безцінні токени. Журі оцінює саме роботу на Devnet: це гарантує, що код реально взаємодіє з блокчейном, а не є локальною симуляцією.
Послідовність розгортання
- Отримайте SOL на Devnet. Використовуйте офіційний faucet або airdrop через CLI: solana airdrop 2.
- Змініть RPC-ендпоінт у конфігурації на Devnet-URL (перевірте актуальний ендпоінт у офіційній документації Solana).
- Зберіть і розгорніть контракти через Anchor CLI або безпосередньо командою `solana program deploy`.
- Зафіксуйте Program ID — він знадобиться для фронтенду та для журі.
- Оновіть фронтенд-конфігурацію — вкажіть Devnet RPC та Program ID.
- Пройдіть повний цикл — підключіть гаманець, виконайте транзакцію, перевірте стан на Solana Explorer (Devnet).
Типові помилки розгортання та їх вирішення
- «Insufficient funds for transaction» — на акаунті гаманця замало SOL для оренди простору під акаунти. Отримайте більше через faucet.
- Program ID не збігається — після повторного deploy Program ID змінюється. Фіксуйте ID після кожного розгортання й оновлюйте фронтенд.
- Фронтенд підключений до Mainnet — двічі перевірте, що RPC-URL вказує саме на Devnet. Транзакції на Mainnet з тестовими даними — це втрата реальних коштів.
- Акаунти не ініціалізовано — переконайтеся, що перед викликом інструкції створено всі необхідні PDA-акаунти.
Як переконатися, що журі зможе запустити проєкт
Журі не буде клонувати ваш репозиторій і збирати проєкт локально, якщо це не є окремою вимогою хакатону. Головне — розгорнутий на Devnet фронтенд за публічним URL та робочі контракти. Додайте в README інструкцію для випадку, якщо хтось із журі захоче запустити локально: середовище, залежності, команди збірки, необхідні ключі.
Наступний крок: оформлення GitHub
Проєкт на Devnet працює — тепер оформіть репозиторій так, щоб журі змогло швидко зрозуміти код.
Як оформити GitHub і README для хакатону
Структура репозиторію, яку очікує журі
Розділіть проєкт на зрозумілі директорії: /programs для смарт-контрактів, /app або /frontend для клієнтської частини, /tests для тестів. Якщо є скрипти для розгортання — винесіть їх у /scripts. Уникайте плоского списку файлів у корені репозиторію.
Що обов'язково має бути в README
- Назва проєкту та одне речення про те, що він робить.
- Посилання на розгорнутий фронтенд (Devnet).
- Program ID на Devnet.
- Інструкція локального запуску: передумови (Node.js версія, Rust, Anchor), команди встановлення залежностей, збірки, розгортання.
- Короткий опис архітектури: які контракти, які інструкції, як вони пов'язані з фронтендом.
- Посилання на demo-відео (якщо вимагається окремо від submission-платформи).
Типові помилки в оформленні репозиторію
- README з одним рядком «Hackathon project» без жодної інструкції.
- Закомічені .env-файли з приватними ключами — це критична помилка безпеки, навіть на Devnet.
- Величезні бінарні файли або build-артефакти в репозиторії.
- Відсутність .gitignore — журі бачить node_modules або target-папки.
Як перевірити, що репозиторій відкривається та запускається
Клонуйте репозиторій у чисту папку на іншій машині (або у чисту VM). Дотримуйтесь власної інструкції з README буква в букву. Якщо на будь-якому кроці щось ламається — виправте інструкцію або налаштування. Журі не буде гадати, чого бракує.
Наступний крок: запис demo
Репозиторій готовий — далі запис технічного demo.
Як записати технічне demo
Підготовка середовища до запису
Закрийте всі зайві вкладки та програми. Вимкніть сповіщення. Переконайтеся, що Devnet-гаманець має достатньо SOL для всіх транзакцій, які ви плануєте показати. Перевірте, що фронтенд завантажується без помилок у консолі. Запустіть запис двічі: перший раз як репетицію, другий — фінальний.
Структура технічного demo
- Контекст (10–15 секунд): назва проєкту та одна фраза про проблему.
- Демонстрація (60–90 секунд): повний цикл користувацької дії від підключення гаманця до фінального результату. Коментуйте кожен крок: «Зараз я підключаю гаманець... виконую транзакцію... бачу, що стан on-chain оновився».
- Технічна підводка (30–45 секунд): коротко покажіть архітектуру — де контракти, як фронтенд взаємодіє з блокчейном, які PDA використовуються.
- Фінал (10 секунд): що далі (без входу в стартап-стратегію — просто «плануємо додати X і Y»).
Інструменти для запису екрана
Використовуйте вбудовані інструменти ОС (OBS, системний записувач екрана) або браузерні розширення. Вибирайте інструмент, який записує без затримок і не додає водяних знаків у безкоштовній версії. Формат — MP4, роздільна здатність — 1080p.
Як уникнути технічних проблем під час запису
- Не записуйте через VPN, якщо це не необхідно — це додає затримку.
- Майте запасний Devnet-гаманець із SOL на випадок, якщо основний потрапить у rate-limit.
- Якщо транзакція зависає — не чекайте більше 10 секунд на камеру, перезапустіть і скоментуйте: «Перезапускаю — на Devnet іноді трапляються затримки».
Тривалість та формат, який очікує журі
Більшість хакатонів вимагають demo відео від 2 до 5 хвилин. Перевірте офіційний пакет першоджерел поточного хакатону для точного ліміту. Якщо ліміту немає — тримайтеся в межах 3 хвилин. Журі переглядає десятки подань: коротке й чітке demo завжди краще за довге й детальне.
Наступний крок: pitch deck
Demo записано — тепер створіть візуальну презентацію для журі.
Як підготувати pitch deck для хакатону
Обов'язкові слайди хакатонного pitch deck
- Проблема — хто страждає і чому існуючі рішення не працюють.
- Рішення — що саме ви побудували і як це вирішує проблему.
- Як це працює — технічна архітектура на рівні схеми: контракти, фронтенд, зовнішні інтеграції.
- Demo — скріншоти ключових екранів або вбудоване відео (якщо платформа дозволяє).
- Чому Solana — що саме з екосистеми ви використовуєте і чому це не можна було зробити на іншому блокчейні так само ефективно.
- Що далі — наступні кроки розвитку (без деталей стартап-стратегії — лише технічні та продуктові кроки).
Візуальне оформлення та читабельність
Використовуйте не більше двох шрифтів. Текст на слайді має бути читабельним без збільшення — мінімум 24pt для основного тексту. Один слайд — одна ідея. Не перевантажуйте слайди графікою: журі дивиться на презентацію швидко, а не вивчає її як документ.
Як не перевантажити pitch deck технічними деталями
Архітектурний слайд — єдине місце, де технічні деталі доречні. І навіть там показуйте схему, а не код. Не вставляйте фрагменти Rust-коду в pitch deck — для цього є GitHub. Якщо журі цікавиться деталями, вони перейдуть до репозиторію самі.
Наступний крок: фінальна перевірка submission
Pitch deck готовий — далі напишіть опис проєкту та збирайте submission.
Як написати опис проєкту для submission
Яка інформація обов'язкова в описі
- Назва та категорія/трек.
- Опис проблеми та рішення — максимум три речення.
- Технічний стек: Anchor/Rust, фронтенд-фреймворк, використані бібліотеки (якщо специфічні для Solana — обов'язково вкажіть).
- Посилання: фронтенд на Devnet, GitHub, demo-відео.
- Що реалізовано за час хакатону — чесно вкажіть обсяг.
Як стисло пояснити технічну складову для журі
Замість переліку всіх функцій опишіть архітектуру через взаємодію: «Фронтенд на React викликає інструкцію create_vault через Anchor, яка створює PDA-акаунт сховища та мінтує токен частки. Баланси верифікуються через CPI-виклик до SPL Token програми». Журі одразу розуміє, де смарт-контракти, де фронтенд і як вони пов'язані.
Як показати унікальність проєкту в кількох реченнях
Фокусуйтеся на тому, що відрізняє ваш проєкт від існуючих рішень в екосистемі. Не пишіть «ми перші, хто зробив X» — напишіть «на відміну від існуючих рішень, які роблять Y, ми використовуємо Z, що дозволяє...». Конкретна різниця завжди переконливіша за загальні претензії на унікальність.
Приклади сильних описів переможців
Сильний опис читається за 30 секунд і відповідає на три питання: що це, як це технічно працює, чому це цінне для Solana. Слабкий опис — це стіна тексту з переліком усіх фіч, без структури, без посилань, без зрозумілого юзкейсу.
Наступний крок: фінальна перевірка submission
Опис написано — тепер зберіть усе разом і перевірте перед відправленням.
Як перевірити submission перед відправленням
Повний чек-лист submission
- Фронтенд на Devnet відкривається за вказаним URL і завантажується без помилок.
- Повний цикл користувацької дії проходить без crash-багів.
- GitHub-репозиторій публічний, README містить інструкцію запуску та Program ID.
- Demo-відео відтворюється, тривалість відповідає ліміту хакатону.
- Pitch deck завантажується та відкривається коректно (перевірте на іншому пристрої).
- Опис проєкту заповнений у всіх обов'язкових полях платформи.
- Проєкт подано в правильному треку та категорії.
- Усі члени команди додані до submission (якщо платформа це вимагає).
Поширені причини відхилення submission
- Проєкт не працює на Devnet — найчастіша причина. Журі не оцінює «ми майже дописали».
- Неправильний трек — подання в DeFi-трек проєкту, який є суто NFT-колекцією без фінансової логіки.
- Відсутність demo-відео або відео не відтворюється.
- Закритий репозиторій — журі не має доступу до коду.
- Пропущений дедлайн — платформи зазвичай не приймають подання після закриття.
Скільки часу залишити на фінальну перевірку
Мінімум 24 години до дедлайну. За цей час ви встигнете виявити проблеми з доступністю фронтенду, перезаписати demo, якщо відео пошкодилося, та виправити помилки в описі. Останні 6 годин перед дедлайном не призначені для роботи — вони призначені для буфера на випадок технічних проблем із платформою подань.
Що робити, якщо платформа не приймає подання
Не чекайте останньої години. Спробуйте подати чернетку за 48 годин до дедлайну — так ви перевірите, що платформа працює з вашим акаунтом і браузером. Якщо в фінальний момент платформа не відповідає, зробіть скріншоти готового submission з часовою міткою та зверніться до організаторів через офіційні канали. Перевірте актуальні контакти підтримки в пакет першоджерел поточного хакатону.
Наступний крок: очікування результатів
Submission відправлено. Далі — результати, можливі гранти та наступні кроки після хакатону, які розглядаються в окремому розділі.