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

Ви подали заявку на грант, зробили демо для хакатону або виконали баунті — і не перемогли. Код написаний, архітектура продумана, презентація зібрана, але результату немає. У цій точці більшість команд розходяться, а проєкт залишається в локальній гілці репозиторію. Програш не дає грошей чи визнання, але дає щось інше: робочий прототип, розуміння вимог і список людей, які бачили вашу роботу. Нижче — покрокова карта, як це перетворити на портфоліо, контакти й підготовку до наступної спроби.
Розвилка: коли працювати з програшем, а коли відпускати
Не кожен програш варто перетворювати на актив. Є три напрямки, і вибір залежить від того, що саме ви зробили й чому не пройшли.
- Go — продовжувати працювати з результатом. Ви маєте працююче демо, яке вирішує реальне завдання. Ви не пройшли не через якість коду, а через конкуренцію, незручний формат подачі або брак комунікації з журі.
- Pivot — змінювати форму, але зберігати суть. Ідея життєздатна, але формат подачі не підійшов конкретній програмі. Наприклад, ви подалися на грант, а ваш проєкт краще лягає в баунті або як окремий продукт.
- Stop — зупинятися. Проєкт не запустився технічно, ви не отримали фідбеку від журі, а ідея не підтверджена ніким, крім вашої команди. У цьому випадку краще зафіксувати уроки й рухатися далі.
Якщо ви не впевнені, який варіант ваш — перевірте одну річ: чи є у вас працююче демо, яке можна показати сторонній людині за п’ять хвилин без вашої участі. Якщо так — це матеріал для портфоліо. Якщо ні — фіксуйте уроки й закривайте.
Кому підходить цей підхід
Ця інструкція для тих, хто вже вклав час у конкретну заявку й отримав відмову. Це соло-білдери, маленькі команди, студенти й фахівці суміжних професій, які пробують себе в екосистемі Solana через гранти, баунті або хакатони. Якщо ви ще не подали жодної заявки, почніть із загального огляду Гранти, баунті й хакатони без ілюзій.
Цей підхід не підійде, якщо ви шукаєте гарантований результат або очікуєте, що сам факт участі автоматично конвертується в пропозицію. Програш — це сировина, а не готовий продукт.
Що саме можна отримати з програшу
Три види активів, які реально витягти з невдалої участі.
Портфоліо
Не перемога, а сам проєкт. Робоче демо з описом завдання, архітектури й прийнятих рішень. Це кейс, який можна показати при подачі на наступний грант, при спілкуванні з інвестором або як частину профілю. Головна умова: кейс має описувати не ідею, а реалізоване рішення — що було зроблено, які інструменти використані (Rust, Anchor, конкретні бібліотеки), де межі реалізації.
Контакти
Журі, ментори, організатори, інші учасники — ці люди бачили вашу роботу. Навіть якщо ви не перемогли, коректне фолоу-ап спілкування залишає враження. Не кожен контакт перетвориться на співпрацю, але деякі перетворяться.
Підготовка до наступної спроби
Ви знаєте, що не спрацювало: подача, скоп, технічна реалізація, комунікація. Це конкретні точки для виправлення, а не абстрактний «треба краще».
Умови й вимоги: що має бути у вашому проєкті
Щоб програш конвертувався в портфоліо, проєкт має відповідати кільком критеріям. Без них ви не отримаєте ні корисний кейс, ні контакти.
- Працююче демо. Не макет, не відео, не опис. Щось, що можна запустити в devnet-мережі Solana та перевірити.
- Фіксований опис завдання. Що саме ви вирішували, для кого, які обмеження були. Без цього кейс виглядає як технічна вправа, а не як продукт.
- Відкритий код або хоча б структурований репозиторій. Якщо код не можна показати — поясніть чому (наприклад, майбутній комерційний запуск), але підготуйте архітектурний опис, який можна публічно продемонструвати.
- Фідбек від журі або організаторів. Якщо ви його не отримали автоматично — запитайте. Це не гарантує відповідь, але без спроби ви не дізнаєтеся причину.
Дедлайн, статус і офіційне джерело: що перевірити перед наступним кроком
Перш ніж витрачати час на доопрацювання проєкту після програшу, перевірте три речі в офіційних умовах програми, де ви брали участь.
- Права на результат. Чи залишається код вашою власністю після участі? Деякі програми вимагають передачі прав або публічного ліцензування. Перевірте розділ «Intellectual Property» або аналогічний у правилах.
- Обмеження на повторну подачу. Чи можна подавати той самий проєкт на наступний раунд тієї ж програми? Чи вимагається істотна зміна? Якщо обмеження є — ви знаєте мінімальний обсяг доопрацювання.
- Статус програми. Чи продовжується вона взагалі? Не будуйте стратегію навколо програми, яка призупинена або завершена. Перевірте офіційну сторінку організатора та останні оголошення.
Якщо жодного з цих пунктів немає в публічних правилах — запитайте організаторів напряму. Відсутність інформації не означає свободу дій.
Ризики й підготовка: що може піти не так
Робота з програшем має свої ризики, і їх варто розуміти заздалегідь.
- Витрата часу на мертвий проєкт. Якщо ідея не підтверджена ринком, доопрацювання може бути пустою тратою. Мінімізуйте: встановіть ліміт часу на «реанімацію» — наприклад, два тижні. Після цього — або go, або stop.
- Негативне фолоу-ап спілкування. Якщо ви пишете журі з претензіями або проханням «переглянути результат» — це шкодить репутації. Коректний фолоу-ап це: подяка за час, конкретне запитання про фідбек, коротке згадування, що проєкт продовжує розвиток.
- Юридичні обмеження. Якщо ви підписали угоду з організатором — перевірте, чи не забороняє вона публічну демонстрацію результату або використання в портфоліо. Якщо угоди не було, але правила програми містять такі обмеження — вони можуть бути дійсними.
- Ілюзія прогресу. Доопрацювання старого проєкту відчувається як робота, але може не наближати вас до нової подачі. Перевіряйте: кожен крок має відповідати конкретному критерію наступної програми, куди ви плануєте податися.
Покроковий план: від програшу до наступної спроби
- Зафіксуйте результат. Зробіть скріншоти демо, запишіть коротке відео (до двох хвилин), збережіть опис завдання й архітектури. Це базовий матеріал для портфоліо.
- Отримайте фідбек. Напишіть організаторам або журі з конкретним запитом: «Які два-три моменти в нашій подачі були найслабшими?» Не питайте «чому ми не перемогли» — це формулювання провокує розпливчасті відповіді.
- Оцініть контакти. Складіть список людей, з якими ви взаємодіяли під час програми. Відмітьте, з ким була змістовна розмова, а не лише формальне спілкування. Напишіть тим, з ким є сенс підтримати зв’язок — коротко, без прохань.
- Оцініть проєкт за критеріями go/pivot/stop. Працює демо? Є фідбек? Є бажання продовжувати? Якщо хоча б одна відповідь негативна — розгляньте pivot або stop.
- Знайдіть наступну ціль. Не доопрацьовуйте «в загальному» — шукайте конкретну програму, грант або баунті, куди підете наступним. Її критерії стануть вашим чек-листом доопрацювання.
- Адаптуйте подачу. Перепишіть опис проєкту під вимоги нової програми. Це не «копіпаст із минулого разу» — це нова подача, яка враховує, чому ви програли раніше.
- Подайтеся або закрийте. Якщо підготовка зайняла більше часу, ніж ви планували, і проєкт досі не відповідає критеріям — зупиніться. Фіксуйте уроки й рухайтеся до нового.
Критерії go / pivot / stop: підсумок
| Критерій | Go | Pivot | Stop |
|---|---|---|---|
| Працююче демо | Є, запускається | Є частково, потрібні виправлення | Немає або не запускається |
| Фідбек від журі | Отримано, конкретний | Отримано, але розпливчастий | Не отримано й неможливо отримати |
| Наступна програма | Знайдена, критерії зрозумілі | Є кандидати, але треба змінювати формат | Підходящих програм немає |
| Час на доопрацювання | Є резерв, не більше двох тижнів | Потрібен перероблений формат — більше часу | Часу немає або витрати невиправдані |
| Мотивація команди | Є, підтверджена діями | Є, але потребує переорієнтації | Відсутня |
Програш на хакатоні чи у грантовій програмі — не кінець, а точка даних. Що з цими даними зробити, залежить від вашого проєкту, вашого часу й вашої чесності щодо того, чи є сенс продовжувати. Якщо сенс є — наступний крок простий: знайдіть програму, де ваш оновлений кейс відповідатиме критеріям, і подайтеся знову. Якщо сенсу немає — зафіксуйте, що зробили, і білдьте далі. Інші маршрути для творців і команд є в розділі Будувати на Solana: від ідеї до працюючого продукту.
Редакція солана.укр
