Готовність до демо та розгортання

1. Демо — це сценарій, а не стендап із ноутбуком

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

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

Для цього зручно тримати в голові зовсім коротку структуру показу:

Проблема → вхідні дані → дія → результат → цінність

Якщо взяти, наприклад, Landing Optimizer, погане демо виглядає так: ходите по вкладках, перепрошуєте за некрасивий експорт — ревʼюер ввічливо дивиться і всередині тоне. Хороше виглядає інакше: одна landing page, натискаєте аналіз, отримуєте список гіпотез із пріоритетами й пояснюєте, чим це корисно маркетологу. Один сценарій, одна цінність, одна дуга.

Тут дуже допомагає неприємна, але корисна думка: демо не зобов’язане показати весь проєкт — воно зобов’язане показати найкращий і найнадійніший зріз. Пʼять фіч у capstone, а стабільно працює одна — показуйте її; решта живе в README, screenshots, обмеженнях і планах. Це не слабкість, а інженерна чесність, яка цінується вище за крихку браваду.

2. Для показу потрібен не прод, а передбачуваний demo slice

Розводити demo-ready і production-ready заново вже не потрібно: stop/go для цього лежить у DEMO_QUALITY_GATE.md. Тут важливий практичний висновок: для показу потрібен не найбільш «дорослий» сетап, а найпередбачуваніший demo slice.

Ваша мета не довести, що ви вмієте викочувати проєкт, а доставити core flow без рулетки. Тому далі корисно дивитися не на престиж, а на передбачуваність: локальний запуск, віддалений стенд і fallback — три способи показати один сценарій.

3. Deploy не завжди обов’язковий

Після слів «підготувати демо» майже автоматично зʼявляється інший внутрішній голос: «треба терміново викотити в хмару, інакше не солідно». Це зрозуміла реакція. Розгортання виглядає доросло, у нього є URL, на нього приємно дивитися здалеку — але для навчального capstone він частіше джерело ризику, а не посилення. Тут корисно порівняти три режими показу.

Для більшості capstone-проєктів локальне відтворюване демо — найкращий базовий вибір. Особливо якщо у вас уже є зрозумілий docker compose up, demo data лежать у репозиторії, а README дає короткий quickstart. Ревʼюеру важливий не модний домен, а те, що ви за хвилини піднімаєте проєкт і не залежите від падіння середовища. Мінімальний локальний сценарій часто елегантніший за хмару:

docker compose up -d
# Піднімаємо локальне середовище

python -m app demo --sample data/sample.csv
# Запускаємо демонстраційний сценарій

Якщо ж ваш deploy вже готовий і стабільно нудний — це чудово: наприклад, Landing Optimizer живе на Vercel, відкривається за одним URL, sample page зашита в інтерфейс, без ручного прогріву. Але ключове слово тут — вже: не перетворюйте останній тиждень спринту на «терміново викочуємо хоч кудись».

Під deploy readiness у межах цієї лекції ми розуміємо не production-експлуатацію, а річ набагато скромнішу: якщо ви все-таки показуєте віддалений стенд, він має бути передбачуваним. Стабільна адреса, зрозумілий вхід, заготовлені demo data й поруч fallback на випадок, якщо хмара захоче влаштувати театральну паузу. Інакше гарний URL перетворюється на гарну точку відмови.

4. Фолбек — це частина демо, а не план провалу

Найспокійніший захист — не той, де нічого не ламається, а той, де навіть поломка вже передбачена. Саме тому fallback — не запасний стілець у коридорі, а нормальна частина demo-сценарію. Ви не вигадуєте його в момент падіння live середовища: він уже лежить у DEMO.md, протестований і навіть трохи нудний. А нудний fallback — дуже хороша новина. Логіку fallback зручно тримати у вигляді короткого ланцюжка:

flowchart TD
    A[Live demo] -->|якщо все добре| B[Показуємо основний сценарій]
    A -->|якщо стенд не відповідає| C[Локальний запуск]
    C -->|якщо локальний запуск теж капризує| D[Записане відео]
    D -->|якщо потрібен швидкий огляд| E[Скриншоти + walkthrough]

Сама ідея проста. Первинний шлях — найкращий живий сценарій; ламається — переходите до вторинного, не перезапускаючи навмання. Останній рубіж, screenshots walkthrough, показує цінність без ризику збою, навіть коли життя вирішило пожартувати. Дуже корисно прописати це прямо в demo script:

## Якщо live demo не спрацювало

1. Перейти на локальний запуск за quickstart.
2. Якщо локальний сценарій недоступний — відкрити `docs/demo.mp4`.
3. Якщо відео недоречне — показати screenshots із `docs/screens/`.

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

Для Personal CFO fallback особливо корисний, тому що сценарій там нерідко залежить від завантаження CSV. Імпорт у браузері закапризував — потрібен другий шлях: готовий звіт, CLI-варіант або скриншоти на sample data. Важливо не натискати ту саму кнопку, а зберегти цінність і результат.

5. Один проєкт — різні формати показу

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

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

curl -X POST http://localhost:8000/api/analyze \
  -H "Content-Type: application/json" \
  -d @data/sample-request.json
# У відповіді приходить список гіпотез із пріоритетами

Якщо ваш проєкт — це CLI або звіт, як буває в частини automation- і data-oriented capstoneʼів, формат теж може бути дуже чистим:

python -m cfo summary --month 2026-04
# Звіт збережено в reports/2026-04.md

І це абсолютно нормальне демо. Ба більше, іноді таке демо краще за вебінтерфейс: коротше, детермінованіше, чесніше.

Для migration slice або legacy modernization основна цінність узагалі може бути не в «гарному UI», а в доказі, що ви зберегли поведінку й отримали зелену валідацію. Тоді хороше демо — це не танці навколо інтерфейсу, а зв’язка «до/після», validation report, smoke check і walkthrough по diff або звіту. Не гламурно, зате інженерно переконливо.

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

6. Пишемо зрозумілий DEMO.md

Тепер перейдемо до документа, який збирає все це в одну керовану штуку. У цій лекції я використовую коротке імʼя DEMO.md; якщо у вас у репозиторії прийнято варіант DEMO_README.md, суть та сама — це ваш demo script, а не окрема маркетингова сторінка. Тут ролі розділяються просто: README.md — quickstart і обмеження, DEMO_QUALITY_GATE.md — внутрішній stop/go перед репетицією, DEMO.md — сам маршрут показу, demo data, expected result і fallback.

Найкорисніший каркас для DEMO.md:

# Сценарій demo

## Setup
...

## Команда для запуску
...

## Demo-дані
...

## Кроки сценарію
...

## Очікуваний результат
...

## Якщо live demo зламається
...

## Що пояснювати
...

Кожен розділ тут виконує дуже конкретну роботу. У Command to run має стояти реальна команда, а не абстракція «запустити застосунок». У Demo data sample inputs лежать у репозиторії або доступні за зрозумілим шляхом, а не зберігаються в папці Downloads під назвою новий файл (17).csv.

Для Landing Optimizer блок сценарію може бути приблизно таким:

## Кроки сценарію

1. Відкрити сторінку локального стенда.
2. Вставити demo URL лендинга.
3. Натиснути Analyze.
4. Отримати список гіпотез із пріоритетами.

А для Personal CFO — іншим:

## Кроки сценарію

1. Завантажити `data/sample-transactions.csv`.
2. Запустити категоризацію.
3. Показати місячне зведення.
4. Відкрити блок recurring subscriptions.

Розділ Expected result особливо корисний тим, що заздалегідь фіксує, що вважається успішним проходженням сценарію, і прибирає спокусу на льоту змінювати трактування під те, що вийшло. А розділ What to explain стримує вас від читання коду вголос: чому обрано саме цей slice, що він вирішує, що свідомо залишено поза межами. Інакше кажучи, DEMO.md — це документ, який робить виступ коротшим, а проєкт — зрозумілішим.

7. Репетиція як тест відтворюваності

Найчесніший тест готовності проходить не у вас у голові й не тоді, коли ви самі вперше-в-другe відкриваєте свій проєкт, а коли інша людина бере ваш DEMO.md і намагається відтворити сценарій. У цей момент дуже швидко зʼясовується все цікаве: що команда була «і так зрозуміла», а насправді ні, що sample data лежать не там, а README припускає ритуал, відомий лише автору. Загалом починається дуже корисна правда.

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

У цьому місці особливо добре починають працювати вже знайомі вам артефакти. README.md відповідає за вхід і запуск. DEMO_QUALITY_GATE.md підказує, чи можна взагалі йти на репетицію. EVIDENCE_LOG.md допомагає пояснити, що ви перевіряли в спринті. DEMO.md задає маршрут показу. А чесні обмеження в README знімають зайве напруження: ревʼюер не чекає того, чого ви самі не обіцяли. Усе складається в спокійну систему, а не в набір героїчних «аби тільки гарно показати».

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