Гранти для DefTech: як підготувати продукт, команду й заявку без слабких місць

Що саме фінансують DefTech-гранти

П’ять перевірок продукту до роботи над заявкою

Як упакувати технічну частину

Бюджет: перекладіть технічний план мовою витрат

Команда, якій повірять і яка справді виконає проєкт

Як написати заявку, яку легко перевіряти

Облік і документи треба налаштувати до першої витрати

Реалістичний план підготовки за шість тижнів

Типові помилки, через які сильний продукт виглядає слабко

Фінальний чекліст перед поданням

Висновок

У DefTech сильна ідея ще не дорівнює сильній грантовій заявці. Експертам потрібно побачити не лише перспективну технологію, а й керований проєкт: конкретну потребу користувача, підтверджений рівень готовності, компетентну команду, вимірюваний результат і бюджет, пов’язаний із роботами. Для директора це також питання фінансової дисципліни. Розібратися, як читати показники, контролювати витрати й перевіряти документи перед підписанням, допомагає курс бухгалтерського обліку для директорів у навчальному центрі «Стимул».

Як відправну точку для пошуку фінансування варто переглянути сторінку «Грант для розробників оборонних технологій» на порталі Дія.Бізнес. Водночас назви програм, пріоритети, суми, строки та вимоги змінюються, тому інформацію з оглядової сторінки потрібно звіряти з чинним положенням конкретного конкурсу безпосередньо перед поданням. У цій статті умови наведено станом на 14 жовтня 2026 року.

Що саме фінансують DefTech-гранти

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

Станом на 14 жовтня 2026 року Brave1 повідомляє про кілька моделей підтримки. У класичній грантовій програмі йдеться про суми до 500 тис., 2 млн, 4 млн і 8 млн грн залежно від технологічної готовності продукту. Спецгрантова програма передбачає підтримку до 8 млн грн у пріоритетних напрямах незалежно від рівня готовності, а окремі грантові конкурси формуються під конкретні технічні характеристики. Це різні інструменти з різною логікою відбору, а не шкала, на якій достатньо вибрати найбільшу суму.

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

Починайте не із суми, а з розриву в готовності

Корисно описати поточний і цільовий стани продукту одним реченням. Наприклад: «Зараз маємо лабораторний зразок модуля, який пройшов стендові тести; за проєктом виготовимо три польові прототипи, перевіримо їх за погодженою методикою та усунемо критичні відмови». Таке формулювання одразу задає перелік робіт, закупівель, тестів і доказів.

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

П’ять перевірок продукту до роботи над заявкою

1. Проблема має належати конкретному користувачеві

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

2. Потрібен доказ, а не лише опис можливості

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

До заявки варто додавати не красиву демонстрацію, а відтворювані результати тестів із прив’язкою до версії прототипу.

3. Рівень готовності повинен відповідати фактам

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

4. Архітектура має витримувати не лише демонстрацію

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

5. Є шлях від прототипу до застосування

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

Як упакувати технічну частину

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

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

Бюджет: перекладіть технічний план мовою витрат

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

Спочатку сформуйте структуру декомпозиції робіт

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

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

Перевірте кошторис трьома сценаріями

• Базовий: ціни й строки відповідають отриманим пропозиціям постачальників.
• Стресовий: критичний компонент дорожчає або затримується; команда знає, що переноситься, а що замінюється.
• Мінімальний: визначено недоторканне ядро робіт, без якого заявлений результат неможливий.

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

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

Команда, якій повірять і яка справді виконає проєкт

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

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

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

Як написати заявку, яку легко перевіряти

Сильна заявка має одну логічну лінію:

потреба → поточний доказ → технічна прогалина → роботи → вимірюваний результат → бюджет → спосіб перевірки.

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

Корисна формула для кожного етапу

Опишіть етап у чотирьох рядках: вхідний стан, роботи, вихідний результат і критерій приймання. Наприклад: «На вході — інтегрований прототип версії 0.3. Команда виготовляє корпуси, збирає три зразки та проводить серію стендових тестів. На виході — три працездатні зразки версії 0.4 і протокол. Етап прийнято, якщо всі зразки проходять визначені перевірки за однаковою методикою».

Ця формула не гарантує перемоги, але усуває типову двозначність: чи фінансується процес, чи досягнення результату.

Облік і документи треба налаштувати до першої витрати

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

Практичний мінімум для внутрішнього контролю:

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

Якщо облік ведеться в BAS або 1С, не обов’язково відразу перебудовувати всю систему. Часто достатньо аналітики за проєктом, статтею бюджету, етапом і договором, а також звіту, який зіставляє дані обліку із затвердженим кошторисом. Але таку модель треба протестувати на умовній закупівлі до підписання грантового договору.

Реалістичний план підготовки за шість тижнів

Тиждень 1: відповідність і межі

Оберіть конкретну програму, прочитайте чинне положення, складіть перелік формальних вимог і стоп-факторів. Зафіксуйте продукт, версію, цільовий результат і суму, яку реально обґрунтувати.

Тиждень 2: докази та прогалини

Проведіть інвентаризацію протоколів, тестів, фото, технічних документів і зворотного зв’язку. Не створюйте докази заднім числом: позначте прогалини та заплануйте додаткові перевірки.

Тиждень 3: роботи, ризики й команда

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

Тиждень 4: кошторис і календар

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

Тиждень 5: чернетка та незалежне читання

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

Тиждень 6: контрольна збірка

Перевірте форми, підписи, формати файлів, допустимий обсяг, назви додатків і строк подання. Збережіть фінальну копію всього пакета та підтвердження відправлення. Не відкладайте завантаження на останню годину.

Типові помилки, через які сильний продукт виглядає слабко

• Заявка починається з технології, а не з потреби. Читачеві доводиться здогадуватися, навіщо продукт потрібен.
• Майбутні характеристики подано як уже досягнуті. Це руйнує довіру до всіх доказів.
• Сума обрана за принципом «скільки дають». Немає зв’язку між грошима та переходом продукту на новий рівень.
• Кошторис живе окремо від календаря. Закупівлі запізнюються відносно тестів або не покривають заявлену кількість зразків.
• Ризики приховано. Експерти все одно бачать залежності, але не бачать здатності команди ними керувати.
• Немає власника фінансової звітності. Після перемоги технічна команда витрачає час на відновлення документів.
• Використано застарілі умови. Суми, пріоритети чи форми беруть із давньої публікації замість чинного положення.

Фінальний чекліст перед поданням

• Обрана програма відповідає продукту, стадії та статусу заявника.
• Умови, суми й строки перевірено за чинними документами на дату подання.
• Поточний рівень готовності підтверджено матеріалами, а не самооцінкою.
• Ціль проєкту описує один зрозумілий технологічний перехід.
• Кожен етап має результат, критерій приймання, строк і відповідального.
• Кожна витрата пов’язана з роботою та дозволена правилами програми.
• Кількість зразків однакова в технічному описі, календарі й кошторисі.
• Ризики мають власників, ранні індикатори та план реагування.
• Команда розуміє порядок закупівель, обліку, зберігання документів і звітності.
• Пакет не містить зайвих чутливих відомостей і відповідає вимогам доступу.
• Заявку перечитала незалежна людина, а фінальна версія збережена окремо.

Висновок

Підготовка до DefTech-гранту — це корисна діагностика бізнесу навіть без гарантії перемоги. Вона змушує відокремити факти від припущень, перевірити технічну зрілість, побачити реальну собівартість наступного етапу та призначити відповідальних. Сильна заявка не намагається справити враження масштабом обіцянок. Вона показує контрольований перехід від уже підтвердженого стану до результату, який можна прийняти, облікувати й застосувати на практиці.