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

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

З чого починається відмова: типова помилка заявки

Більшість заявок будуються за одним шаблоном: «Ми будуємо платформу для X на Solana. Ось що вона вміє. Нам потрібно стільки-то коштів». Рев’юер бачить у цьому три прогалини одночасно: незрозуміло, чи проблема існує насправді, чи є хоча б один свідок цієї проблеми, хто саме буде це робити і чому саме стільки грошей.

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

Кому підходить цей формат підготовки

Цей підхід корисний, якщо ви:

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

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

Проблема: як описати так, щоб її побачили

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

Що працює

• Формулювання через дію: «Користувач хоче зробити X, але зараз йому доводиться Y, що займає стільки-то часу або коштує стільки-то».
• Вказівка на межу: «Існуючі рішення не підтримують Z» — за умови, що ви далі пояснюєте, чому Z важливо, а не просто перелічуєте відсутні фічі.
• Обмеження кола: ви чітко кажете, для кого саме ви вирішуєте проблему, а не для «всіх користувачів Solana».

Що не працює

• «Проблема в тому, що немає нашого продукту» — це тавтологія, а не проблема.
• «Ринок зростає на X% на рік» — це контекст, а не проблема конкретної людини.
• «Web3 потребує більше інструментів» — занадто загально, рев’юер не зрозуміє, де саме ви бачите свій внесок.

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

Доказ: що рахується за аргумент, а що — за побажання

Доказ — це найслабший блок у більшості заявок. Заявники часто плутають доказ із переконанням.

Рівні доказу, від слабкого до сильного

• Припущення: «Користувачі, мабуть, стикаються з цією проблемою». Це не доказ, це гіпотеза.
• Аналогія: «У DeFi на Ethereum є такий інструмент, а на Solana — ні». Це показує прогалину на ринку, але не доводить попит.
• Зворотний зв’язок: якщо команда справді провела розмови з п’ятьма релевантними користувачами й зафіксувала однакову проблему, це сильніший сигнал, ніж абстрактне «людям має сподобатися». Важливо описати, хто входив до вибірки, що саме вони робили й у якому контексті виникла проблема.
• Поведінковий доказ: «Ми зробили мінімальну версію, і за тиждень її використали N людей без нашого просування». Це найсильніший рівень, який доступний до подачі заявки.

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

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

Команда: що показувати, коли вас мало

Грантові комітети не шукають повні CV. Вони шукають відповідність між тим, що потрібно зробити, і тим, хто це буде робити.

Що включити

• Ролі, а не титули: не «СЕО», а «відповідає за продукт і взаємодію з користувачами». Не «розробник», а «пише смарт-контракти на Rust, має досвід із Anchor».
• Конкретний досвід: не «3 роки в IT», а «зробив X, результат Y». Якщо досвіду в веб3 немає — вкажіть релевантний досвід поза ним.
• Час: скільки годин на тиждень кожен учасник реально може витрачати на проєкт. Це особливо важливо для соло-білдерів і студентів.

Що робити, якщо ви соло

Не вигадуйте команду. Напишіть, що ви працюєте самі, вкажіть свою компетенцію чесно і поясніть, як плануєте закривати ті зони, де вам не вистачає навичок. Це краще, ніж перелічувати людей, які «можуть приєднатися», але не підтвердили участь.

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

План використання коштів: від сум до логіки

План коштів — це не таблиця з цифрами. Це логіка: «ми отримуємо стільки, робимо ось ці речі, і ось як ви зможете перевірити, що речі зроблено».

Структура, яка працює

• Milestone (етап) — що зроблено — як перевірити — сума. Наприклад: «Етап 1: розгортання смарт-контрактів на devnet. Перевірка: відкритий репозиторій і деплой-скрипт, який рев’юер може запустити. Сума: X».
• Прозорі категорії: розробка, аудит, інфраструктура, живі витрати. Уникайте «маркетинг» на ранніх стадіях — це червоний прапор для більшості грантових програм.
• Реалістичні оцінки: якщо ви просите кошти на три місяці повної зайнятості для двох людей — сума має відповідати ринковим ставкам, а не бути випадковим числом.

Типова помилка

Просити гроші на весь проєкт одразу, коли ви ще не зробили жодного етапу. Більшість програм краще реагують на запит фінансування першого конкретного етапу з чітким результатом, ніж на запит «на все».

Як перевірити: прочіть кожен milestone і запитайте себе: «Якщо я отримаю гроші, зроблю це і покажу результат — чи буде достатньо цього, щоб організатор сказав "етап виконано"?» Якщо результат розмитий — milestone потрібно конкретизувати.

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

Перш ніж подавати заявку, перевірте чотири речі, які часто пропускають:

• Права на результат. Деякі програми вимагають, щоб код був відкритим (open-source). Інші дозволяють закритий код, але з обмеженнями. Якщо ви плануєте будувати бізнес на цьому коді — перевірте ліцензійні умови до подачі.
• Географічні обмеження. Частина програм не працює з резидентами певних країн. Це не залежить від вашої етнічності чи мови — це юридична обмеженість платника. Перевірте правила конкретної програми.
• Час на підготовку. Якісна заявка займає від кількох днів до тижня. Якщо дедлайн через добу — ви, ймовірно, подаєте не готовий матеріал, а чернетку.
• Конкуренція. Грант — це не замовлення. Навіть ідеальна заявка може не пройти через обмеженість бюджету програми. Трактуйте це як тест гіпотези, а не як єдиний план.

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

Наступний крок: безпечна перевірка перед подачею

Не подавайте заявку одразу після написання. Зробіть одну річ: дайте прочитати її людині, яка не займається Solana і не знає вашого проєкту. Попросіть її відповісти на три питання:

1. Яку проблему вирішує цей проєкт?
2. Чому автори вірять, що проблема існує?
3. Що конкретно буде зроблено за грантові кошти і як це можна перевірити?

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

Коли всі чотири блоки — проблема, доказ, команда, план коштів — проходять цей тест, ви маєте не ідеальну заявку, а заявку, яка відповідає своєму призначенню. Далі — подача, очікування й робота над наступним етапом, незалежно від результату. Грант у портфоліо — це добре, але робочий продукт, який ви білдите паралельно, важливіший за будь-яку заявку.

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