solana.org.ua
Українська спільнота Solana: нові матеріали, безпека та подіїСпільнота Solana в TelegramПриєднатися →
Шаблони, чек-листи та інструменти

Шаблони та чек-листи для стартапів і хакатонів

Нижче наведено робочі шаблони та чек-листи, які можна скопіювати й заповнити безпосередньо на цій сторінці. Кожен ресурс містить структуру, критерії та обмеження — усе, що потрібно для перевірки ідеї, планування MVP, підготовки pitch deck та подачі проєкту на…

0 підрозділів0 матеріалів на цьому рівніОновлено 1 серпня 2026

Нижче наведено робочі шаблони та чек-листи, які можна скопіювати й заповнити безпосередньо на цій сторінці. Кожен ресурс містить структуру, критерії та обмеження — усе, що потрібно для перевірки ідеї, планування MVP, підготовки pitch deck та подачі проєкту на Solana-хакатон.

Шаблон перевірки стартап-ідеї

Призначення шаблону

Шаблон призначений для швидкої перевірки життєздатності стартап-ідеї до написання коду чи залучення коштів. Допомагає виявити логічні прогалини на етапі, коли змінити напрямок ще недорого.

Структура перевірки

  1. Проблема. Формулювання однією фразою. Хто страждає, як часто, які наслідки.
  2. Цільова аудиторія. Конкретний сегмент, а не «всі користувачі криптовалют». Вік, географія, поведінка, готовність платити.
  3. Існуючі рішення. Перелік альтернатив (включно з офчейн). Чому вони не задовольняють потребу.
  4. Пропоноване рішення. Як саме ваш продукт усуває проблему. Де Solana є необхідною, а не декоративною.
  5. Монетизація. Модель доходу: комісія за транзакцію, підписка, токеноміка, RWA-комісія тощо.
  6. Технічна здійсненність. Чи існують потрібні смарт-контракти, оракули, ліквідність у потрібних пулів. Чи вистачить throughput мережі.
  7. Ризики. Регуляторні, технічні (зупинка кластера, експлойти в Anchor), конкурентні.

Критерії оцінки ідеї

  • Проблему можна підтвердити розмовами з мінімум 10 потенційними користувачами.
  • Solana використовується не «бо модно», а тому що альтернативи (EVM, L2, централізовані рішення) об'єктивно гірші для цього юзкейсу.
  • Монетизація зрозуміла без багаторівневих токеномічних схем.
  • Технічний стек не вимагає створення інфраструктури, якої ще не існує (наприклад, власного оракула для унікальних даних).
  • Ризики мають хоча б один конкретний план пом'якшення, а не абстрактне «ми це вирішимо пізніше».

Обмеження шаблону

Шаблон не замінює ринкове дослідження, юрисконсульта чи аудит смарт-контрактів. Він дає структурне мислення, але не гарантує, що ідея комерційно успішна. Не підходить для оцінки pure infra-проєктів (валідатори, RPC-вузли) — для них потрібні інші метрики.

Версія ресурсу

Чернетка. Версія не фіксована, оновлення залежать від змін у екосистемі Solana.

План MVP на чотири тижні

Призначення плану

План дозволяє команді з 2–4 осіб вийти на робочий прототип за чотири тижні. Орієнтований на хакатонні та pre-seed сценарії, де головне — довести core loop, а не зробити ідеальний UI.

Структура тижневого плану

Тиждень 1. Фундамент і контрактна логіка.

  • Описати core user flow текстом (3–5 кроків).
  • Розгорнути локальний Anchor-проєкт, налаштувати тестовий валідатор (solana-test-validator).
  • Реалізувати основний смарт-контракт: стейт-машину, ключові інструкції, базові помилки.
  • Написати тести для критичного шляху (happy path + 2–3 edge cases).

Тиждень 2. Інтеграція та фронтенд.

  • Підключити фронтенд до контракту через Anchor IDL.
  • Реалізувати підключення гаманця (WalletAdapter).
  • Відобразити ключовий стейт і дозволити користувачу виконати основну дію.
  • Базова обробка помилок транзакцій (відображення логів користувачу).

Тиждень 3. Полірування та devnet-тестування.

  • Розгорнути контракт на devnet.
  • Протестувати повний цикл з реальними гаманцями (airdrop SOL на devnet).
  • Виправити помилки, що виникли на devnet, але не на локальному валідаторі (різниця в таймінгах, лімітах).
  • Додати мінімальну навігацію та пояснення для журі.

Тиждень 4. Submission-пакет і стабілізація.

  • Записати демо-відео (2–3 хвилини).
  • Підготувати pitch deck і README.
  • Фінальне тестування: перевірити всі кроки submission-чек-листа.
  • Зарезервувати час на форс-мажори (падіння devnet, проблеми з деплоєм).

Критерії готовності MVP

  • Користувач із реальним гаманцем може пройти повний цикл без втручання розробника.
  • Основний смарт-контракт має мінімум 80% покриття тестами критичного шляху.
  • Проєкт працює на devnet, а не лише на локальному валідаторі.
  • Наявні pitch deck, README і демо-відео.

Обмеження плану

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

Версія ресурсу

Чернетка. Версія не фіксована, оновлення залежать від змін у екосистемі Solana.

Шаблон pitch deck

Призначення шаблону

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

Структура слайдів

  1. Назва й one-liner. Назва проєкту. Одне речення, що пояснює, що ви робите.
  2. Проблема. Конкретна ситуація, цифри або приклад, який журі зрозуміє без контексту.
  3. Рішення. Як ваш продукт вирішує проблему. Де саме задіяна Solana.
  4. Як це працює. Спрощена діаграма: користувач → фронтенд → смарт-контракт → on-chain результат. Без вихідного коду.
  5. Ринок. TAM/SAM/SOM або хоча б оцінка кількості потенційних користувачів із поясненням логіки.
  6. Конкуренти. Таблиця: ви vs 2–3 альтернативи за ключовими параметрами.
  7. Прогрес. Що зроблено: контракт задеплоєний, X тестів, Y користувачів на devnet.
  8. Команда. Імена, ролі, релевантний досвід. Без довгих біографій.
  9. Що далі. Конкретні наступні кроки: mainnet, грант, інтеграція з конкретним протоколом.
  10. Контакти. GitHub, Twitter, email.

Порядок заповнення

Почніть зі слайдів 2 і 3 (проблема та рішення) — якщо вони не переконують, решта не має значення. Далі — слайд 4 (як працює), потім 6 (конкуренти). Слайди 1, 5, 7–10 заповніть останніми. Не перевищуйте 12 слайдів для хакатонної подачі.

Обмеження шаблону

Шаблон не містить дизайн-макетів і не замінює професійну підготовку інвестиційної палубки для раундів вище pre-seed. Для Series A і далі потрібна інша структура з фінансовими моделями та юніт-економікою.

Версія ресурсу

Чернетка. Версія не фіксована, оновлення залежать від змін у екосистемі Solana.

Робочий чек-лист submission для Solana-хакатону

Призначення чек-листа

Чек-лист гарантує, що submission-пакет відповідає типовим вимогам Solana-хакатонів (наприклад, на платформах Devpost чи аналогічних). Перевірте конкретні правила свого хакатону — вони можуть відрізнятися.

Етапи підготовки submission

Етап 1. Код і розгортання.

  • Репозиторій публічний, без залежностей, що вимагають ключів доступу.
  • Основний смарт-контракт задеплоєний на devnet (перевірте адресу в README).
  • Фронтенд розгорнутий і доступний за URL (Vercel, Netlify, GitHub Pages тощо).
  • У репозиторії є інструкція для локального запуску.

Етап 2. Демонстрація.

  • Відео записане, тривалість від 1 до 3 хвилин.
  • Відео показує реальну взаємодію з проєктом, а не лише скріншоти.
  • Аудіо зрозуміле, текст на екрані читабельний.

Етап 3. Документи.

  • Pitch deck завантажений у форматі PDF.
  • README містить: опис, архітектуру, інструкцію запуску, посилання на розгортання.
  • Заповнена форма submission на платформі хакатону (всі обов'язкові поля).

Фінальна перевірка перед подачею

  • Відкрийте посилання на фронтенд у режимі інкогніто — переконайтеся, що сторінка завантажується без авторизації.
  • Спробуйте пройти користувацький шлях самостійно з іншого пристрою.
  • Перевірте, чи не залишилися порожні секції, тестовий текст або службові позначки в pitch deck і README.
  • Переконайтеся, що команда вказана правильно і всі учасники додані до submission.
  • Збережіть чернетку submission і зробіть скріншот за 30 хвилин до дедлайну.

Обмеження чек-листа

Чек-лист базується на типових вимогах, але кожен хакатон може мати унікальні правила (обов'язкові треки, обмеження за стеком, додаткові артефакти). Обов'язково звіртеся з офіційними правилами конкретного заходу — цей чек-лист не їх замінює.

Версія ресурсу

Чернетка. Версія не фіксована, оновлення залежать від змін у екосистемі Solana.

Шаблон README для хакатонного проєкту

Призначення шаблону

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

Структура хакатонного README

  1. Назва та one-liner. Те саме речення, що в pitch deck.
  2. Опис. 3–5 речень: проблема, рішення, чому Solana.
  3. Архітектура. Текстова діаграма або список компонентів: фронтенд (стек), смарт-контракти (Anchor, версія), зовнішні залежності.
  4. Передумови. Node.js від X, Rust від Y, Solana CLI, Anchor CLI. Точні версії, які ви тестували.
  5. Локальний запуск. Покрокова інструкція: clone, install, build, deploy локально, запустити фронтенд. Кожна команда — окремий рядок.
  6. Devnet-розгортання. Адреса контракту на devnet, посилання на працюючий фронтенд.
  7. Тести. Як запустити тести, що вони перевіряють.
  8. Відомі обмеження. Що не встигли зробити, що працює частково.
  9. Команда. Імена, нікнейми, ролі.
  10. Ліцензія. Вказати ліцензію (наприклад, MIT або Apache 2.0).

Порядок заповнення

Заповніть блоки в порядку нумерації. Блок 4 (передумови) перевірте останнім: встановіть усе з нуля на чистій машині або в новому Docker-контейнері. Якщо інструкція не спрацьовує з нуля — виправте її, а не припиняйте перевірку.

Обмеження шаблону

Шаблон не містить інструкцій для production-розгортання, CI/CD пайплайнів, моніторингу чи аудит-підготовки. Він орієнтований виключно на хакатонний контекст, де головне — відтворюваність і зрозумілість.

Версія ресурсу

Чернетка. Версія не фіксована, оновлення залежать від змін у екосистемі Solana.

Джерела