Від імпровізації до процесу. Як оборонній компанії перейти від прототипу до серії і зберегти швидкість

В Україні прототип під запит підрозділу роблять дуже швидко, і майже завжди за цим стоїть один інженер на постійному зв’язку з військовими. Поки компанія мала, цього вистачає. Проблеми починаються, коли замовник просить вже не один виріб, а партію в сотні чи тисячі штук на місяць. Про те, як до цього підготуватися, 1 жовтня 2026 року говорили на другому воркшопі серії Validated & Fundable, який Defence Builder провів разом з European Defense Tech.

Зафіксуйте відповідального за роботу з підрозділами

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

За цю роботу має відповідати окрема людина, наприклад польовий інженер, який звітує безпосередньо керівнику R&D. Він структурує неформальні відгуки для розробників, складає карту тестувань і зберігає всі відгуки на сервері компанії. З часом ця база стає основою для наступних версій виробу, бо навіть дрібне зауваження з поля може першим показати, що противник змінив тактику чи засоби.

З мого досвіду, для такої роботи треба постійно бути в Україні. Коли я працював консультантом з оборонних технологій, до мене зверталися компанії з Каліфорнії, які приїжджали тестуватися раз на рік. На мою думку, цього вже недостатньо. Варто мати власний R&D-офіс в Україні або принаймні польового інженера. Якщо немає ні того, ні іншого, можна шукати інтегратора, якому військові вже довіряють.

Оформіть права до першого тесту

Права на продукт треба зафіксувати до першої зустрічі з підрозділом, бо після неї все неоформлене стає предметом дискусії. За моїми спостереженнями, ще кілька років тому тестування в Україні нагадувало Дикий Захід, але тепер правил значно більше. Помилка в комплаєнсі може коштувати прав на продукт, а іноді й поставити під питання саме існування компанії.

Усе, що створюють засновники, працівники й підрядники, має письмово належати компанії. Заздалегідь зафіксуйте, що ви напрацювали до початку співпраці з військовими, і перевірте ліцензії на іноземні компоненти. Окремо подбайте про NDA (угоду про нерозголошення), щоб інженер, який іде з команди, не забрав розробку з собою.

Перечитайте й угоду з інвесторами. Я кілька разів бачив, як фонд заходив у компанію ще на етапі pre-seed, а команда не перевіряла, чи дозволяють його умови тестувати й розвивати продукт в Україні. Українські партнери теж перевірятимуть вас, зокрема на зв’язки з рф та на присутність вас чи ваших підрядників у санкційному списку OFAC (Управління з контролю за іноземними активами Мінфіну США), тому документи для цього краще підготувати до приїзду.

Збирайте і зберігайте докази

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

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

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

Тестуйтеся там, де у вас купуватимуть

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

Тому шукайте підрозділи, які воюють в тих умовах і з тими загрозами, під які ви робили продукт, і чия задача відповідає профілю виробу. Наземні роботизовані комплекси (НРК), наприклад, логічно тестувати в бригаді безпілотних систем або механізованій.

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

Заходити до підрозділу варто офіційно, через Test in Ukraine від Brave1, пілот експериментального бойового застосування Міноборони або інтегратора. Фраза «у нас є знайомий у бригаді» має насторожити. Якщо за доступ до тестування просять гроші, варто відмовитися й звернутися до одного з цих офіційних каналів.

Де межа між тестом і спільною розробкою

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

Тому ще до початку тестів зафіксуйте, що саме ваша компанія розробила самостійно, і оформіть домовленості про тестування. Це можна зробити, зокрема, через інтегратора. Інакше потім буде складно довести, де закінчилося тестування і почалася спільна розробка.

У цьому питанні я також рекомендую ознайомитись із Законом України № 4585-IX від 21 серпня 2025 року, який регулює розподіл прав інтелектуальної власності на об’єкти, створені військовослужбовцями у зв’язку з проходженням служби.

Готуйте серію ще на прототипі

Прототип можна зібрати з COTS (Commercial Off-The-Shelf), тобто цивільних комплектуючих без обмежень на закупівлю, але для великої серії ті самі компоненти знадобляться тисячами. Тому ще під час розробки варто перевірити, чи є постачальник, готовий поставляти потрібну кількість, чи немає обмежень експортного контролю або залежності від недружніх країн. Окремо варто з’ясувати, чи витримають такі обсяги ваші підрядники в потрібні строки.

Документація потрібна, щоб сотий виріб працював так само, як перший, а той, що повернувся в ремонт через пів року, можна було полагодити. Якщо виріб уже кодифіковано, тобто йому присвоєно код для закупівель Міноборони, навіть невелика зміна може запустити кодифікацію заново. Тому краще одразу розуміти, які покращення можна внести оновленням програмного забезпечення (ПЗ), не чіпаючи основну конструкцію.

Що перевірити перед масштабуванням

Перед масштабуванням варто поставити собі шість запитань і визначити, хто на них відповідає.

1. Чи всі засновники, працівники й підрядники письмово передали права компанії?
2. Чи є людина, яка відповідає за роботу з підрозділами і звітує керівнику R&D?
3. Чи зафіксовано письмово, кому належать дані з тестувань?
4. Чи створені умови для того щоб оператор міг повідомити про проблему з телефона менш ніж за дві хвилини?
5. Скільки днів минає від звіту про несправність до виправлення в полі?
6. Які виправлення можна внести оновленням ПЗ, а які запустять повторну кодифікацію?

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