Чотири тижні — це типовий формат онлайн-хакатону на Solana, який дає достатньо часу для створення робочого прототипу, але не залишає простору для затягування. Нижче — покроковий розпис із контрольними точками, який можна брати за основу й адаптувати під конкретний склад команди та обрану ідею.
Тиждень 1: ідея, архітектура, прототип
Перший тиждень визначає, чи буде проєкт узагалі реалізований. Головне завдання — перейти від розмитого бачення до конкретної технічної схеми й першого візуального прототипу.
Вибір ідеї та обмеження
Команда фіксує одну ідею й одразу прописує межі: що точно входить до хакатонної подачі, а що навмисно виключається. Типова помилка — узятися за платформу-все-в-одному замість одного чітко вирішеного сценарію.
Архітектурне рішення
Розробник (або техлід) малює блок-схему: які смарт-контракти потрібні, як вони взаємодіють між собою через CPI (Cross-Program Invocation — виклик однією програмою іншої на Solana), де живе фронтенд, який RPC-провайдер використовується. На цьому етапі важливо визначити, чи потрібні PDA (Program Derived Address — похідні адреси програми для безпечного зберігання стану), скільки акаунтів створює одна транзакція й чи не перевищить вона ліміт обчислювальних одиниць.
Візуальний прототип
Дизайнер або фронтенд-розробник збирає мокапи в Figma або навіть статичний HTML/CSS-макет. Прототип не містить логіки, але показує, куди користувач клікає, які дані вводить і що бачить у відповідь. Це дозволяє всій команді говорити про один і той самий інтерфейс, а не уявляти його кожному по-своєму.
Розподіл ролей
Усі учасники чітко знають свої зони відповідальності: хто пише смарт-контракти, хто фронтенд, хто готує pitch deck, хто тестує. Якщо ролі перетинаються — це ок, але має бути одна людина, яка приймає фінальне технічне рішення.
Тиждень 2: розробка ядра та інтеграція з Devnet
Другий тиждень — це чиста розробка. Жодних нових фіч, лише реалізація того, що зафіксовано в архітектурі.
Смарт-контракти на Devnet
Розробник розгортає програми на Solana Devnet (тестова мережа). Кожен контракт деплоїться окремо, перевіряється через CLI або інструменти на кшталт Solana Explorer на Devnet: чи створюються потрібні акаунти, чи проходять транзакції, чи правильні дані зберігаються в стані.
Фронтенд і підключення до контракту
Фронтенд підключається до розгорнутих контрактів через geyser-плагіни або стандартні RPC-виклики. На цьому етапі важливо перевірити підписання транзакцій гаманцем (наприклад, Phantom) і коректну передачу інструкцій. Якщо фронтенд і контракт живуть у різних репозиторіях — час об'єднати їх у спільне середовище.
Мінімальна зв'язність
До кінця другого тижня користувач має мати змогу виконати хоча б один повний цикл: натиснути кнопку на фронтенді, підписати транзакцію, побачити зміну стану в контракті й відображення результату в інтерфейсі. Це не фінальний продукт, але це доказ, що архітектура працює.
Тиждень 3: поліпшення, тестування, виправлення помилок
Третій тиждень присвячений стабільності. Робочий, але крихкий прототип перетворюється на щось, що можна показати журі без ризику падіння на сцені.
Обробка крайових випадків
Що станеться, якщо користувач натисне кнопку двічі? Якщо гаманець не має достатньо SOL для комісії? Якщо RPC-провайдер поверне таймаут? Кожен такий сценарій має бути оброблений: або блокуванням кнопки, або зрозумілим повідомленням про помилку, або повторною спробою.
Тестування на Devnet
Команда проганяє весь сценарій від початку до кінця кілька разів з різними гаманцями. Перевіряється не лише «щасливий шлях», а й навмисні помилки: спроба відправити неправильні дані, відхилення транзакції в гаманці, втрата з'єднання. Усі знайдені баги фіксуються в загальному списку з пріоритетами.
Оптимізація досвіду користувача
Дизайнер і фронтенд-розробник доопрацьовують інтерфейс: додають індикатори завантаження, зрозумілі стани помилок, пояснення того, що відбувається після підписання транзакції. Журі оцінює не лише код, а й те, наскільки зрозуміло продукт спілкується з користувачем.
Тиждень 4: demo, pitch deck, submission
Останній тиждень — це не розробка. Це пакування результату в формат, який журі може оцінити за кілька хвилин.
Підготовка demo
Demo — це записаний відеоролик (зазвичай 3–5 хвилин), у якому показано повний цикл взаємодії з продуктом. Відео знімається в реальному середовищі на Devnet, без монтажних «чарівників». Оператор або диктор коментує кожну дію: що натискається, чому, який результат очікується. Якщо транзакція зависає — це не monte, а реальний ризик, тому в demo краще показати стабільний сценарій.
Pitch deck
Презентація (зазвичай 5–10 слайдів) відповідає на питання: яку проблему вирішуєте, як саме, чому саме на Solana, що зроблено за хакатон, що далі. Текст на слайдах — мінімум, максимум — у голосовому супроводі. Дизайн не має відволікати від змісту.
Submission
Фінальна подача збирається відповідно до вимог платформи хакатону: відео, pitch deck, посилання на репозиторій, розгорнутий контракт на Devnet, інструкція для журі (якщо потрібна). Усе завантажується завчасно — не в останню годину, коли платформа може дати збій.
Як адаптувати план, якщо команда стартувала пізніше
Якщо ви вступили в хакатон на другому або третьому тижні, план не стискається пропорційно — він обрізається за пріоритетами.
- Пропускається візуальний прототип. Замість нього — текстовий опис екранів і взаємодій. Фронтенд одразу пишеться в робочому середовищі.
- Архітектура спрощується до одного контракту. Ніяких CPI, ніяких складних ланцюжків. Один контракт, одна основна дія, один фронтенд.
- Тиждень тестування скорочується до двох днів. Тестується лише «щасливий шлях». Крайові випадки обробляються базово: блокування кнопки, повідомлення про помилку.
- Pitch deck мінімізується. П'ять слайдів: проблема, рішення, технічна реалізація, demo, команда. Без аналізу ринку й фінансових прогнозів.
Головне правило пізнього старту: краще подати один повністю робочий сценарій, ніж три недороблених.
Чек-лист контрольних точок для кожного тижня
| Тиждень | Контрольна точка | Критерій готовності |
|---|---|---|
| 1 | Архітектура зафіксована | Написана блок-схема, перелік контрактів, типи акаунтів, точки взаємодії з фронтендом |
| 1 | Візуальний прототип | Мокапи всіх ключових екранів зрозумілі всім учасникам команди |
| 2 | Контракти на Devnet | Усі контракти задеплоєні, базові транзакції проходять через CLI |
| 2 | Перша зв'язність | Фронтенд відправляє транзакцію, контракт змінює стан, інтерфейс оновлюється |
| 3 | Стабільність | Повний сценарій проходить без падінь тричі поспіль на різних гаманцях |
| 3 | Обробка помилок | Кожна точка взаємодії має зворотний зв'язок у разі невдачі |
| 4 | Demo записане | Відео відповідає вимогам хакатону за тривалістю та форматом |
| 4 | Submission завершено | Усі матеріали завантажені, посилання робочі, доступ для журі перевірено |
Наступний крок: визначення складу MVP
Після того як план розписано, потрібно чітко визначити, що саме входить до хакатонного MVP, а що навмисно залишається за межами подачі. Це окремий і критично важливий етап, який розглядається детально в матеріалі про те, що має входити в хакатонний MVP.