Так. Більшість хакатонів на Solana не вимагають від кожного учасника вміти писати код. Журі оцінює готовий проєкт, а не окремі навички кожного члена команди. Якщо ви приносите іншу експертизу — дизайн, стратегію, комунікацію — ви не просто «допомагаєте», а формуєте половину того, що бачить і оцінює журі.
Актуальність: Для теми «Чи можна брати участь у хакатоні без програмування» відкриті позиції, суми винагород, правила та дедлайни змінюються. Станом на 2 серпня 2026 року остаточні умови потрібно звіряти на офіційній сторінці конкретної можливості перед поданням заявки.
Які ролі доступні непрограмістам
Дизайнер інтерфейсів та досвіду
Відповідає за те, як користувач взаємодіє з dApp (децентралізованим додатком). На хакатоні це не лише красиві екрани, а й логіка переходів, станів помилок, підключення гаманця, відображення транзакцій. Фінальний demo часто показує саме інтерфейс — і якщо він незрозумілий, технічна досконалість смарт-контрактів залишається за кадром.
Що конкретно робити: прототип у Figma, адаптивність під мобільний, дизайн токеноміки для екрану, іконки та ілюстрації для pitch-деки.
Продакт-менеджер та бізнес-аналітик
Визначає, що саме команда будує і для кого. На хакатоні це критично: розробники схильні фокусуватися на технічній складовій, а продакт-менеджер повертає фокус до користувача та проблеми. Формуєє критерії готовності MVP, розставляє пріоритети фіч, слідкує щоб команда не витратила 48 годин на другу фічу, коли перша ще не працює.
Що конкретно робити: опис проблеми та рішення для submission, структура pitch-деки, аналіз конкурентів у треку, координація між розробниками та дизайнером.
Маркетолог та комунікатор
Відповідає за те, як проєкт звучить і сприймається. На хакатоні це не рекламні кампанії, а чітке позиціонування: одна речення, яке пояснює, що ви робите. Готує pitch-текст, слайди, допомагає розробникам сформулювати технічну частину мовою, зрозумілою для журі.
Що конкретно робити: написання тексту для submission, підготовка сценарію demo, назва проєкту та one-liner, структура відповідей на запитання журі.
Який внесок очікує журі від непрограмістів
Журі не оцінює «допомогу» — воно оцінює результат. Ось що конкретно впливає на бали:
- Зрозумілість проблеми. Якщо за 30 секунд не зрозуміло, яку проблему вирішує проєкт — бали втрачаються незалежно від коду.
- Якість demo. Журі бачить інтерфейс, чує розповідь, дивиться на слайди. Це зона відповідальності непрограмістів.
- Реалістичність ринку. Аналіз цільової аудиторії, конкурентів, ніші — це не технічне завдання, але воно прямо впливає на оцінку комерційного потенціалу.
- Завершеність подачі. Заповнений submission-формуляр, коректний опис, відео-презентація — журі звертає увагу на те, наскільки команда серйозно поставилася до формальностей.
Типова помилка: непрограміст приходить «підстрахувати» і в результаті не має чіткого артефакту, за який журі може дати бали. У вас має бути конкретний результат — деки, прототип, текст submission.
Як знайти команду, яка шукає непрограміста
Команди, які складаються лише з розробників, часто усвідомлюють потребу в дизайні чи pitch-підготовці, але не знають, де знайти людей. Є кілька робочих каналів:
- Офіційний Discord хакатону. Розділ #team-formation або аналогічний. Не просто пишіть «шукаю команду» — вкажіть роль і що конкретно ви принесете: «UX-дизайнер, зроблю прототип dApp у Figma за перші 12 годин».
- Twitter/X. Хештег хакатону + ключові слова «looking for designer» або «need pitch help». Англійська мова тут працює краще.
- Telegram-спільноти Solana Ukraine. Локальне середовище, де можна знайти українськомовні команди.
Коли пишете про себе, уникайте розмитих формулювань на кшталт «роблю усе що потрібно». Вкажіть одну-дві сильні ролі та конкретний артефакт, який ви гарантуєте.
Детальніше про формати пошуку, чек-лист першої розмови з командою та червоні прапорці — у матеріалі Як знайти команду для хакатону.
Приклади переможних проєктів із сильними непрограмістськими ролями
Конкретні назви та результати минулих хакатонів змінюються від сезону до сезону, тому наводимо типові патерни, які регулярно потрапляють у призові місця:
- DeFi-інструмент із складним інтерфейсом. Технічна частина — стандартний смарт-контракт на Anchor. Перемога завдяки тому, що дизайнер створив інтуїтивний дашборд із візуалізацією ризиків, і журі змогло зрозуміти цінність без розбору коду.
- Інфраструктурний проєкт для розробників. Перемога не через унікальний код, а через те, що продакт-менеджер чітко описав use case, зібрав фідбек від п’яти команд-потенційних клієнтів під час хакатону і показав реальний попит.
- NFT-проєкт із наративом. Технічно — базовий mint на Metaplex. Перемога через комунікацію: маркетолог сформулював сюжетну лінію, підготував pitch, який журі запам'ятало серед десятків технічних демо.
Спільне в усіх цих випадках: технічна частина була достатньою, але не унікальною. Різницю зробила не-технічна складова.
Межі: що все ж потребує технічної участі
Чіткі межі, щоб не потрапити в пастку:
- Смарт-контракт чи бекенд має бути в команді. Ви не можете замінити розробника «простим інструментом no-code», якщо трек вимагає розгортання на Solana. No-code рішення для блокчейну обмежені, і журі перевіряє код.
- Розгортання на devnet. Хтось у команді має вміти деплоїти програму, налаштовувати RPC, працювати з PDA (Program Derived Address). Це технічне завдання.
- Інтеграція з гаманцем. Підключення Phantom або Solflare до фронтенду — мінімальний технічний поріг, який вимагає розробника.
Якщо ви прийшли без жодного технічного учасника — ви не готові до хакатону. Мінімум: один людина, яка здатна розгорнути працюючий прототип на devnet.
Наступний крок: пошук команди
Визначилися з роллю? Перейдіть до практичного пошуку: які канали перевірити, як скласти повідомлення, що написати в першій розмові та які червоні прапорці сигналізують, що команда вам не підходить. Читайте далі: Як знайти команду для хакатону.