Pitch deck для хакатону відрізняється від стартапного: тут не треба доводити ринкову придатність на роки вперед. Ваше завдання — за 5–7 слайдів пояснити, що ви зробили, чому це має значення саме зараз і чому ваша команда здатна це реалізувати. Журі дивить десятки подань, тому кожен слайд має нести конкретну інформацію без води.

Обов'язкові слайди хакатонного pitch deck

Оптимальний обсяг — 7–10 слайдів. Менше — не вистачить для аргументації, більше — журі не дочитає. Нижче — мінімальна структура, якої дотримуються переможці.

Проблема та рішення

Перший слайд визначає, чи продовжить журі читання. Формулюйте проблему в одному реченні: хто стикається з труднощами і що саме не працює. Рішення — теж одне речення: що саме ви побудували, щоб усунути цю проблему.

  • Помилка: «Ми революціонізуємо DeFi на Solana» — це не проблема і не рішення.
  • Правильно: «Трейдерам на Solana бракує інструменту для відстеження власних PDA-адрес у реальному часі. Ми зробили дашборд, який агрегує дані з RPC-вузлів і показує зміни балансів за 2 секунди».

Якщо проблема не зрозуміла за 5 секунд — слайд треба переписувати.

Як це працює (технічно просто)

Цей слайд пояснює архітектуру без занурення в код. Показуйте блок-схему: користувач → фронтенд → смарт-контракт (Anchor) → Solana → результат. Вкажіть, які ключові компоненти ви реалізували за час хакатону.

  • Які смарт-контракти написані (Rust, Anchor)
  • Де розгорнуто фронтенд
  • Які зовнішні дані використовуються (API, оракли)
  • Чи є крос-чейн взаємодія, і якщо так — як саме

Журі має побачити, що ви розумієте, як частини системи сполучаються, а не просто склали їх разом.

Ринок та користувачі

Для хакатону достатньо вузького сегмента. Не треба малювати TAM/SAM/SOM — це стартапова територія. Вкажіть конкретно: хто перший користувач вашого продукту і чому йому це потрібно вже завтра.

  • Приклад: «Наша цільова аудиторія — автори RWA-токенів на Solana, яким треба верифікувати документи без виходу з екосистеми. Перший користувач — команда X, яка зараз верифікує вручну».

Якщо не можете назвати хоча б одну конкретну персону чи команду, яка скористається продуктом — сегмент сформульовано занадто абстрактно.

Команда та ролі

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

  • Мінімум для Solana-проєкту: розробник смарт-контрактів, фронтенд-розробник, людина, яка відповідальна за pitch і продукт.
  • Добре мати: дизайнера, DevOps, спеціаліста з безпеки.

Не пишіть «усі робили все» — це сигнал, що ніхто не відповідав за результат. Чіткі ролі показують організацію.

Дорожня карта після хакатону

Три пункти: що ви зробите за наступні 30, 60 і 90 днів. Без фінансових прогнозів і оцінок — це для стартап-пітчів. Тут важливо показати, що проєкт не помре після закінчення події.

  • 30 днів: виправити баги, знайдені під час хакатону, додати базову обробку помилок на фронтенді.
  • 60 днів: залучити перших 10 тестувальників із цільового сегмента, зібрати фідбек.
  • 90 днів: подати заявку на грант або акселератор.

Конкретні кроки, а не «ми масштабуємося на весь ринок».

Візуальне оформлення та читабельність

Pitch deck для хакатону читатимуть на екрані ноутбука, часто збільшеним до 150–200%. Тому:

  • Мінімальний розмір шрифту — 18 pt. Усе, що менше, журі не читатиме.
  • Не більше 40–50 слів на слайді. Якщо треба більше — розділіть на два слайди або скоротіть.
  • Контрастність. Світлий текст на темному фоні або навпаки. Перевірте, як виглядає на екрані за яскравого світла — хакатони часто проходять у конференц-залах.
  • Скріншоти замість описів. Замість тексту «наш інтерфейс має три вкладки» — покажіть скріншот інтерфейсу з підписаними стрілками.
  • Єдиний стиль. Один шрифт заголовків, один — для тексту, одна палітра кольорів. Не використовуйте більше трьох кольорів.

Формат — PDF. Не PowerPoint, не Google Slides посиланням. PDF гарантовано відкриється на будь-якому пристрої без збійів верстки.

Як не перевантажити pitch deck технічними деталями

Це найчастіша помилка розробників на хакатонах. Pitch deck — не технічна документація. Журі складається з різних профілів: не лише інженери, а й продуктові менеджери, інвестори, комунікатори.

Правило розподілу: максимум 20% слайдів можуть містити технічні деталі. Це зазвичай один слайд «Як це працює». Усе решта — проблема, користувач, ринок, команда, roadmap.

Що не треба включати:

  • Фрагменти коду — для цього є технічне demo та репозиторій.
  • Детальне описання PDA-дерев, CPI-викликів чи структури акаунтів — залиште для питань або документації.
  • Бенчмарки продуктивності, якщо вони не є ключовою перевагою проєкту.
  • Перелік усіх залежностей і версій пакетів.

Що можна згадати технічно, якщо це релевантно:

  • Використання Anchor — це стандарт, просто вкажіть.
  • Нестандартне рішення (наприклад, власний оптимізований RPC-клієнт) — коротко, одним реченням.
  • Безпека: чи пройшли аудит, чи використовували перевірені патерни.

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

Наступний крок: фінальна перевірка submission

Коли pitch deck готовий, він стає частиною загального подання. Переконайтеся, що:

  • PDF-файл важить менше ніж 10 МБ — великі файли можуть не завантажитись у формі подання.
  • Назва файлу містить назву проєкту та слово «pitch» (наприклад, solana-guardian-pitch.pdf), а не final_v3_correct.pdf.
  • Інформація в pitch deck не суперечить тому, що ви показуєте в demo та описуєте в текстовій заявці.
  • Усі імена учасників та назви проєкту збігаються з реєстраційними даними.

Після перевірки pitch deck переходьте до фінальної перевірки submission — там зібрано повний чек-лист перед відправленням.

Джерела