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

Повний чек-лист submission

Пройдіться за цим списком пункт за пунктом. Жоден елемент не є необовʼязковим — організатори перевіряють кожен.

Відео demo завантажено та відтворюється

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

GitHub-репозиторій відкритий та містить README

  • Репозиторій має статус Public, а не Private.
  • У корені репозиторію є файл README.md.
  • README містить: назву проєкту, короткий опис, інструкцію зі встановлення та запуску, перелік технологій (Rust, Anchor, фронтенд-стек тощо).
  • У комітах є історія розробки — це свідчить, що код писався в рамках хакатону.
  • Репозиторій не містить залежностей, які не встановлюються стандартними командами (наприклад, npm install або anchor build без додаткових кроків).

Pitch deck завантажено

  • Файл завантажено у форматі, який вимагає платформа (зазвичай PDF).
  • Розмір файлу не перевищує ліміт.
  • Файл відкривається коректно — усі шрифти відображаються, графіки на місці, сторінки не порожні.

Опис проєкту заповнений

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

Усі учасники додані до команди на платформі

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

Поширені причини відхилення submission

Ось що найчастіше призводить до дискваліфікації або неприйняття подання:

  • Закритий GitHub-репозиторій. Журі та автоматизовані системи перевірки не мають доступу до коду. Це абсолютний дискваліфікуючий фактор.
  • Відео недоступне або не відтворюється. Посилання на Google Drive з обмеженим доступом, завантаження у форматі, який платформа не підтримує, або битий файл.
  • Неповний склад команди. Хтось із розробників не прийняв запрошення, і його немає у списку — такий учасник не отримає приз навіть у разі перемоги.
  • Подання після дедлайну. Платформи фіксують час подання автоматично. Навіть одна хвилина запізнення — це відхилення.
  • Відсутність README або порожній опис. Журі не зможе швидко зрозуміти, що робить проєкт, і перейде до наступного.
  • Проєкт не відповідає обраному треку. Якщо ви подаєтеся у трек DeFi, а проєкт є NFT-маркетплейсом без фінансової логіки — організатори можуть перевести подання у загальну категорію або відхилити.
  • Порушення ліцензій. Використання закритого або ліцензійного коду без дозволу, плагіат чужих рішень.

Скільки часу залишити на фінальну перевірку

Мінімум — 2 години до закриття подань. Оптимально — 4 години. Це не перестрахування, а раціональний буфер на випадок непередбачуваних проблем.

Чому стільки:

  • Завантаження великого відеофайлу може зайняти 15–30 хвилин залежно від зʼєднання.
  • Виявлення того, що GitHub-репозиторій випадково залишився закритим, потребує зміни налаштувань і повторної перевірки доступу.
  • Якщо платформа дає збій або перевантажена в останню годину, у вас буде час спробувати ще раз.
  • Колеги з команди можуть виявити, що їх немає у складі, і вам знадобиться час на повторне надсилання запрошень та їх прийняття.

Фіксуйте час завершення перевірки як внутрішній дедлайн команди. Усе, що робиться після нього — лише виправлення критичних помилок, виявлених під час чек-листа.

Що робити, якщо платформа не приймає подання

Дійте за таким алгоритмом:

  1. Зафіксуйте помилку. Зробіть скріншот повідомлення про помилку з видимим часом. Це ваше підтвердження, що ви намагалися подати вчасно.
  2. Перевірте формати та розміри файлів. Найчастіша технічна причина — файл перевищує ліміт або має непідтримуваний формат.
  3. Спробуйте інший браузер або режим інкогніто. Іноді проблема в кеші, розширеннях або блокувальниках реклами.
  4. Зменшіть розмір файлів. Стисніть відео або pitch deck, якщо ліміт перевищено. Для відео достатньо роздільної здатності 1080p і бітрейту 5–8 Мбіт/с.
  5. Зверніться до підтримки. Напишіть у офіційний канал підтримки хакатону (Discord, Telegram або email — дивіться пакет першоджерел). Вкажіть: назву команди, опис проблеми, скріншот помилки, час спроби подання.
  6. Не чекайте відповіді бездіяльно. Паралельно продовжуйте спроби завантажити — часто проблеми з інфраструктурою вирішуються протягом кількох хвилин.

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

Наступний крок: очікування результатів

Після успішного подання submission:

  • Збережіть підтвердження про подання — скріншот або email від платформи.
  • Перевірте у пакет першоджерел, коли очікується оголошення результатів і в якому форматі воно відбувається.
  • Слідкуйте за офіційними каналами хакатону — іноді журі просить додаткові матеріали або призначає інтервʼю з фіналістами з коротким терміном відповіді.
  • Не вилучайте репозиторій і не робіть його закритим до офіційного оголошення результатів.
  • Підготуйтеся до можливого запиту на live demo — переконайтеся, що проєкт стабільно працює на Devnet і ви можете швидко його запустити.

Час очікування — це також момент, щоб задокументувати архітектурні рішення та підготувати відповіді на питання, які журі зазвичай ставить фіналістам: чому саме Solana, як вирішена проблема масштабування, які PDA (Program Derived Address — похідні адреси програми) використані і чому, як забезпечена безпека транзакцій.

Джерела