Демодень без театру: як показати продукт, а не набір слайдів

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

Кому підходить цей підхід

Інструкція корисна, якщо ви:

• Студент або соло-білдер, який вперше подає заявку на хакатон чи баунті в екосистемі Solana
• Маленька команда з працюючим прототипом, яка готується до грантового демодня
• Фаундер, який раніше показував слайди й не отримав фідбек, який можна використати
• Фахівець суміжної професії (дизайнер, маркетолог), який допомагає команді з презентацією

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

Що насправді оцінюють на демодні

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

Що відрізняє продукт від набору слайдів:

• Реальна взаємодія. Ви не розповідаєте, як це працюватиме — ви показуєте, як це працює зараз. Навіть якщо це один транзакційний шлях на devnet-мережі Solana (тестова мережа для розробників, де токени не мають реальної вартості).
• Чіткі межі. Ви кажете не «ми зробили DeFi-протокол», а «зараз користувач може підключити гаманець, зробити свап двох токенів і побачити комісію. Інші функції — на макетах».
• Відповідь на помилку. Якщо щось ламається під час демо, ви пояснюєте причину, а не робите вигляд, що все йде за планом.

Що потрібно для підготовки

Мінімальний працюючий шлях

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

Середовище для демонстрації

Визначте, де саме будете показувати продукт. Варіанти:

• Devnet. Підходить для більшості хакатонів. Перевірте, чи достатньо у вас тестових токенів (SOL на devnet безкоштовні, їх можна отримати через крани — спеціальні сервіси для розробників).
• Локальне середовище. Якщо продукт не потребує блокчейна для базової демонстрації — покажіть локальну версію й чітко скажіть, де закінчується локальне й починається on-chain.
• Mainnet. Зазвичай не вимагається на хакатонах і для перших грантів. Якщо вимагають — перевірте, чи це не червоний прапорець у правилах.

Перед демоднем запустіть продукт у тому самому середовищі, в якому будете показувати. Перевірте з’єднання, версію браузера, наявність тестових токенів на гаманці.

Структура виступу

Замість класичної пітч-деки з десяти слайдів:

1. Одне речення про проблему. Без вступу про те, наскільки великий ринок.
2. Демонстрація. 60–80% часу — живий продукт. Ви або хтось із команди клікає, показуєте екран, коментуєте що відбувається.
3. Межі. Що працює, що не працює, що зробите наступним.
4. Питання. Не «ми шукаємо фінансування», а конкретне запитання до журі: «Чи правильний ми обрали підхід до X?»

Умови й вимоги: що перевірити до подачі

Кожен демодень має свої правила. Перед підготовкою знайдіть в офіційному джерелі (сайт організатора, офіційний репозиторій, анонс у перевіреному каналі) й перевірте:

Що перевірити	Чому це важливо
Час на виступ	Від цього залежить, скільки встигнете показати. П’ять хвилин — лише один шлях. П’ятнадцять — можна додати контекст.
Формат (наживо / запис / асинхронно)	Запис дозволяє перезняти, але жива демонстрація показує, що ви реально керуєте продуктом.
Вимоги до деплою	Деякі організатори вимагають, щоб продукт був доступний за посиланням. Інші — лише живий показ.
Хто в журі	Технічне журі хоче бачити код і архітектуру. Інвестиційне — метрики й бізнес-модель. Підлаштуйте акценти.
Критерії оцінювання	Якщо 50% оцінки — за технічну реалізацію, не витрачайте половину виступу на ринок.

Якщо в правилах не знайшли відповіді — запитайте організаторів до демодня, а не після.

Дедлайн, статус і офіційне джерело

Цей матеріал не прив’язаний до конкретного демодня — тому ми не наводимо дати чи посилання. Але для кожного реального заходу дійте так:

1. Знайдіть первинне джерело. Не анонс у третьому каналі, а офіційний сайт організатора або репозиторій програми.
2. Перевірте актуальність. Чи не минув дедлайн подачі? Чи не змінився формат? Чи є оновлення в останніх публікаціях?
3. Збережіть скріншот правил. Якщо умови зміняться після вашої подачі — у вас буде доказ початкової версії.
4. Перевірте географічні обмеження. Деякі програми обмежені певними регіонами. Це стосується й українських команд — переконайтеся, що ви не виключені автоматично.

Ризики й підготовка

Технічні ризики

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

Оцінні ризики

• Журі очікує інший рівень. Деякі демодні орієнтовані на готові продукти з користувачами. Якщо ви подаєте прототип — перевірте, чи приймають цей рівень. Інакше ви витратите час, а фідбек буде невикористовним.
• Ви переплутали формат. Грантовий демодень — не те саме, що пітч перед інвесторами. Умови гранту зазвичай фокусуються на технічній реалізації й відповідності дорожній карті, а не на ринковому потенціалі.
• Конкуренція в категорії. Якщо п’ять із десяти команд роблять схожий продукт — вашою перевагою має бути не унікальність ідеї, а якість виконання й чесність у показі меж.

Юридичні ризики

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

Безпечний тест перед реальним демоднем

Перш ніж виходити на справжній демодень, проведіть тест:

1. Запросіть двох-трьох людей, які не бачили ваш продукт (не з команди, не з екосистеми обов’язково).
2. Дайте собі стільки ж часу, скільки будете мати на демодні.
3. Покажіть продукт без попереднього пояснення контексту — так само, як буде на заході.
4. Після демонстрації запитайте: «Що, на вашу думку, цей продукт робить?» і «Що здалося незрозумілим?»

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

Що можна покласти в портфоліо

Навіть якщо ви не виграли, демодень дає матеріал для портфоліо:

• Запис демонстрації. Коротке відео (2–5 хвилин) з живим проходженням продукту.
• Опис того, що працює. Конкретний перелік функцій із зазначенням середовища (devnet, локально).
• Фідбек від журі. Якщо отримали коментарі — зафіксуйте їх. Це показує, що ви не просто виступили, а обробили результат.

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

Наступний крок

Виберіть конкретний демодень або хакатон у екосистемі Solana. Знайдіть офіційні правила. Визначте один працюючий шлях у вашому продукті. Запишіть тестову демонстрацію й покажіть людині поза командою. Якщо вона зрозуміла, що ви білдите — ви на правильному шляху.

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

Редакція солана.укр