Прототип за тиждень: який мінімум достатній для першого тесту

Що це змінює для команди

Достатній мінімум — це один працюючий основний сценарій, який доводить вашу головну гіпотезу. Не продукт, не завершений інтерфейс, не повний набір функцій. Щось, що можна запустити, показати потенційному користувачу й отримати реакцію: чи вирішує цей механізм реальне завдання. На Solana це зазвичай один розгорнутий смарт-контракт із мінімальним інтерфейсом або навіть CLI-інструмент (командний рядок), який виконує одну ключову транзакцію.

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

Як виглядає робочий процес

Від гіпотези до сценарію

Перш ніж писати код, сформулюйте гіпотезу одним реченням. Не «зробити платформу для X», а «користувач готовий виконати Y, щоб отримати Z». Саме цю дію й потрібно прототипувати.

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

Що входить до мінімуму

• Один розгорнутий контракт (програма на Rust через Anchor або без нього) на devnet.
• Один шлях взаємодії — мінімальний фронтенд на React або навіть скрипт у командному рядку, який викликає контракт.
• Один тестовий гаманець з devnet-SOL (безкоштовно через кран).
• Один описаний сценарій — що саме робить користувач крок за кроком.

Чого не потрібно

• Авторизації та реєстрації — тестуєте механізм, а не платформу.
• Продакшн-безпеки — це devnet, там немає реальних коштів.
• Мобільної адаптації — достатньо працює в десктопному браузері.
• Інтеграції з іншими сервісами — лише ваш контракт і базова взаємодія.

Типовий тиждень

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

День 3–5. Написання й розгортання контракту на devnet. Мінімальна логіка, без оптимізацій. Головне — транзакція проходить і стан змінюється так, як очікувалося.

День 6. Створення найпростішого способу взаємодії: скрипт або базова сторінка з однією кнопкою. Перевірка на реальному devnet-гаманці.

День 7. Показ трьом–п’яти людям із цільової аудиторії. Фіксація реакції: чи зрозуміли, що відбувається? Чи готові були б це використати? Чи виникли запитання, яких ви не очікували?

Кого зачіпає ця тема

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

Маленькі команди (2–3 людини) — прототип допомагає синхронізуватися: замість довгих обговорень архітектури ви швидко бачите, як ідея виглядає в реальності.

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

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

Що може піти не так

Перебудова замість перевірки

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

Неправильна гіпотеза

Прототип перевіряє гіпотезу. Якщо гіпотеза сформульована розмито («зробити щось корисне для NFT-ком’юніті»), прототип не дасть корисної відповіді. Перед стартом перевірте: чи можна гіпотезу спростувати? Якщо ні — вона занадто загальна.

Плутанина між прототипом і MVP

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

Технічні пастки на Solana

• Devnet-проблеми. Devnet періодично перезапускається, стан не зберігається. Не покладайтеся на збережені дані — фіксуйте результати тесту окремо.
• Різниця devnet і mainnet. Транзакція, яка проходить на devnet, може не пройти на mainnet через обмеження обчислювальних одиниць (compute units) або інші параметри. Прототип доводить логіку, але не доводить продакшн-придатність.
• Складність налаштування середовища. Встановлення Rust, Solana CLI, Anchor — це може зайняти значну частину тижня, якщо ви робите це вперше. Радимо перевірити середовище заздалегідь, до старту самого прототипу.

Вартість помилки

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

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

Після показу прототипу оцініть результати за трьома критеріями:

Go. Користувачі зрозуміли ідею, проявили інтерес, запитали «коли буде можна скористатися по-справжньому». Наступний крок — планування MVP, оцінка ресурсів, вибір між грантом, баунті, самофінансуванням або бізнес-моделлю. Корисно також подивитися на карту конкурентів, щоб зрозуміти, як відрізнити свій майбутній продукт.

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

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

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

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