Jak przygotować demo produktu na targi lub konkurs, żeby nie zawiodło przez Wi Fi

Po co w ogóle myśleć o demie niezależnym od Wi‑Fi

Dlaczego internet na wydarzeniach prawie zawsze zawodzi

Targi, hackathony i konkursy startupowe mają jedną wspólną cechę: gigantyczne zagęszczenie urządzeń. Setki telefonów, laptopów, tabletów i telewizorów próbują jednocześnie złapać sygnał i pobrać coś z sieci. Nawet jeśli organizator zamówił „mocne łącze”, to fizycznie nie jest w stanie zagwarantować, że w chwili twojego pitchu będzie ono stabilne i dostępne.

Do tego dochodzą typowe problemy techniczne: zakłócenia, ściany, metalowe konstrukcje stoisk, a także niewłaściwie skonfigurowane access pointy. Często sieć jest formalnie dostępna, ale:

• ping skacze tak, że każde żądanie HTTP trwa kilka sekund,
• pakiety się gubią – aplikacja „mieli” i nic się nie dzieje,
• sieć ma agresywne zabezpieczenia (firewall, proxy) blokujące API, WebSockety czy nietypowe porty.

Efekt z perspektywy obserwatora jest zawsze taki sam: stoisz na scenie, mówisz o nowoczesnej technologii, klikasz „Zaloguj” – i widzowie patrzą przez kilkanaście sekund na kółko ładowania. To nie wygląda na „innowację”, tylko na brak przygotowania.

Prezentacja slajdowa vs. interaktywne demo produktu

Prezentacja slajdowa (PowerPoint, Keynote, Google Slides) jest najmniej wrażliwa na problemy z internetem. Po wgraniu wszystkiego lokalnie jedyne ryzyko to rzutnik i pilot. Interaktywne demo produktu rządzi się innymi zasadami – każde kliknięcie może uruchamiać połączenie z serwerem, płatnością, integracją z zewnętrznym API.

Jeżeli demo aplikacji webowej na stoisku ładuje każdy ekran z sieci produkcyjnej, to jedno przycięcie internetu psuje cały efekt. Z kolei aplikacja mobilna, która przy starcie musi się zalogować do chmurowego backendu, bez sieci po prostu nie wejdzie do środka. To zupełnie inny poziom ryzyka niż slajdy na laptopie bez internetu.

Dlatego nie wystarcza „ładny front”. Trzeba potraktować demo produktu jak osobny projekt: ustalić, co ma się wydarzyć, jak to zadziała bez Wi‑Fi i jak zareagujesz, kiedy łącze padnie w najgorszym możliwym momencie.

Mit: „organizator zapewnia szybkie Wi‑Fi, więc wystarczy się podłączyć”

Mit brzmi znajomo: w mailach od organizatora widzisz informację „na hali będzie szybkie Wi‑Fi dla wystawców”, więc planujesz stabilne demo na targi oparte w 100% na tym, że będziesz online. To prosta droga do stresu.

Rzeczywistość jest inna. Organizator może:

• udostępnić tylko jedno Wi‑Fi dla wszystkich, bez gwarancji jakości,
• zmienić hasło lub konfigurację w dniu wydarzenia bez wcześniejszej informacji,
• mieć ograniczone wsparcie techniczne – nikt nie będzie debugował twoich API przed wejściem na scenę.

Nie chodzi o złą wolę. Po prostu priorytetem organizatora jest, aby „coś działało dla większości”, a nie żeby twoje konkretne demo wchodziło w każdej chwili w interakcję z kilkoma zewnętrznymi serwisami. Jeśli twoja prezentacja zależy od ich Wi‑Fi, oddajesz los w nie swoje ręce.

Konsekwencje wpadki z niedziałającym demem

W świecie startupów i innowacji „pierwsze wrażenie” jest często jedyną szansą. Jury konkursu, inwestorzy czy potencjalni partnerzy mają w kalendarzu kilka, kilkanaście pitchy pod rząd. Gdy twoje demo się wysypie, zapamiętają głównie to, że „coś nie działało”.

Kluczowe konsekwencje wpadki z powodu Wi‑Fi:

• utrata wiarygodności technologicznej – jeśli nie ogarniasz prostego demo, pojawia się pytanie, jak ogarniesz system na produkcji,
• zmarnowane minuty pitchu – zamiast opowiadać o przewagach produktu, tłumaczysz się z internetu,
• zawiedzione oczekiwania zespołu – poczucie porażki, mimo że sama jakość produktu może być wysoka.

To nie jest tylko kwestia „pecha”. To wynik przyjęcia założenia, że infrastruktura, na którą nie masz wpływu, zadziała idealnie. Tymczasem zawodowcy zakładają odwrotnie: co może pójść nie tak – pójdzie nie tak. I projektują demo jak teatr: z dopracowanym scenariuszem, rekwizytami, próbami i zapasowym planem na każdą scenę.

Demo jak teatr: scenariusz, rekwizyty, próby, backup

Interaktywne demo na targach warto traktować jak przedstawienie teatralne. Aktor wychodząc na scenę też ma:

• dokładnie opisany scenariusz (kto co mówi i kiedy),
• sprawdzone rekwizyty (nie psują się w dłoni),
• próby generalne (sprawdzony każdy krok),
• plan B (co zrobić, gdy ktoś zapomni tekstu).

Tak samo demo: potrzebuje jasno określonego celu, przygotowanego sprzętu, powtórzonych wiele razy sekwencji kliknięć oraz „siatki bezpieczeństwa” w postaci trybu offline, nagrania wideo i slajdów. To nie jest przesadna ostrożność – to standard pracy zespołów, które regularnie wygrywają konkursy i zbierają leady na targach.

Jak określić, co dokładnie ma robić demo (i co może pójść nie tak)

Jasny cel: co odbiorca ma zapamiętać po 3–5 minutach

Pierwsze pytanie nie brzmi „jak przygotować demo produktu na targi technicznie”, tylko: co odbiorca ma zrozumieć po tych kilku minutach. Na przykład:

• „To narzędzie automatyzuje raporty księgowe w jednym kliknięciu”.
• „Ta aplikacja skraca proces zamówienia z 10 minut do 30 sekund”.
• „Nasz system w czasie rzeczywistym pokazuje obciążenie maszyn na hali produkcyjnej”.

Z tego wynika, jakie funkcje w ogóle trzeba pokazać. Jeśli celem jest „jeden klik i gotowy raport”, to trzyminutowy tour po wszystkich ustawieniach systemu jest zbędny. Im bardziej klarowny cel, tym prostsze i tym stabilniejsze będzie twoje demo, bo wyrzucisz z niego cały zbędny hałas.

Wybór kluczowych funkcji – mniej znaczy stabilniej

Najczęstsza pułapka: próba pokazania wszystkiego. Startup, który budował produkt rok, chce w 5 minut wcisnąć prezentację każdego ekranu i integracji. Technicznie oznacza to dziesiątki punktów, w których coś może się wysypać: błąd ładowania, brak odpowiedzi z API, bug UI.

Bezpieczniejsza zasada: maksymalnie 2–3 kluczowe ścieżki, które prowadzą prosto do „momentu wow”. Reszta może pozostać w materiałach dodatkowych na stoisku. Zamiast opowiadać o 12 modułach, pokaż:

1. logowanie (lub start bez logowania, jeśli nie jest niezbędne dla efektu),
2. jedną, dobrze dopracowaną ścieżkę użytkownika,
3. finalny efekt – raport, podsumowanie, ekran wyniku.

Każdy dodatkowy ekran to dodatkowe ryzyko. Dla stabilnego demo na targi minimalizm jest sprzymierzeńcem, a nie ograniczeniem.

Mapowanie zależności od internetu krok po kroku

Kiedy scenariusz jest już szkicowo ustalony, czas rozpisać go technicznie. Warto wziąć kartkę (albo prosty diagram online) i dla każdej akcji zadać pytanie: czy w tym miejscu potrzebuję internetu?. Typowe punkty zależne od sieci:

• logowanie i rejestracja użytkownika,
• pobieranie list (produkty, klienci, zamówienia, zgłoszenia),
• zapisywanie danych na serwer (formularze, zamówienia, raporty),
• integracje zewnętrzne (płatności, mapy, systemy CRM, IoT),
• powiadomienia „na żywo” (WebSocket, SSE, MQTT).

Przy każdym z tych punktów należy zdecydować: czy na potrzeby demo naprawdę muszę iść do sieci? Zaskakująco często odpowiedź brzmi „nie”. Logowanie można zastąpić domyślnie zalogowanym użytkownikiem demo, listy można mieć zaszyte lokalnie, a powiadomienia – zasymulowane na podstawie wcześniej przygotowanych danych.

Scenariusz demonstracji: kto co pokazuje, na jakim sprzęcie

Kiedy wiadomo, które kroki są kluczowe i jak redukować zależności od sieci, przychodzi czas na precyzyjny scenariusz demonstracji. To nie jest ogólny opis typu „pokażemy główne funkcje”. To sekwencja:

• kto trzyma który sprzęt (prezenter, osoba od „backstage’u”),
• na czym dokładnie jest uruchomiona aplikacja (model laptopa/telefonu, system),
• z jakiego konta demo korzystacie,
• które ekran po którym – w jakiej kolejności – ma się pojawić.

Scenariusz warto spisać chociaż w najprostszej formie, np. tabeli:

Taki scenariusz ułatwia dalsze decyzje techniczne i ćwiczenie demonstracji – każdy w zespole wie, czego się spodziewać na ekranie w danej sekundzie.

Co musi być „prawdziwe”, a co można zasymulować

Wokół symulowanych danych w demo krąży sporo nieporozumień. Spotyka się opinie, że „prawdziwy startup pokazuje demo na produkcji, z prawdziwymi danymi w czasie rzeczywistym”. To mit, który generuje niepotrzebne ryzyko.

Sensowne podejście:

• „prawdziwe” powinny być: kluczowa logika produktu (jak działa algorytm, przepływ użytkownika, interfejs), ogólny UX,
• zasymulowane mogą być: dane klientów, realne odpowiedzi z zewnętrznych API, płatności, logowanie SSO.

Jeśli w konkursie jasno mówisz, że pokazujesz demo offline bez internetu, w którym część danych jest pre‑załadowana, to nie ma tu żadnego oszustwa. Jury ocenia produkt, koncepcję, interfejs, a nie to, czy w danej minucie AWS lub Google Cloud zareagują na twoje zapytanie. Ryzyko realnej awarii po stronie zewnętrznego dostawcy tylko rośnie przy wydarzeniach masowych.

Projektowanie demo pod tryb offline lub „pół‑offline”

Tryb offline: dane i logika lokalnie, synchronizacja później

Najbezpieczniejszy sposób na niezależność od Wi‑Fi to zaprojektowanie wersji demo tak, jakby internetu nie było wcale. Cała logika i potrzebne dane powinny być dostępne lokalnie na urządzeniu: w przeglądarce, aplikacji natywnej lub lekkim serwerze zainstalowanym na laptopie.

W praktyce oznacza to:

• użycie lokalnej bazy danych (np. SQLite, IndexedDB, Realm, Core Data),
• zapisanie JSON‑ów z przykładowymi danymi w projekcie,
• pre‑ładowanie wszystkich potrzebnych obrazów, ikon, stylów, skryptów,
• brak żądań do zewnętrznych API podczas sekwencji demonstracyjnej.

Synchronizację z prawdziwym serwerem można włączyć dopiero po wydarzeniu lub w innym trybie aplikacji. Dla prezentacji przygotowujesz dedykowany tryb demo offline, w którym priorytetem jest przewidywalność, a nie aktualność danych z produkcji.

Wykorzystanie lokalnych zasobów: cache, mock serwery, pre‑loadowane pliki

Jeżeli aplikacja ma architekturę webową, możesz:

• postawić na laptopie lokalny serwer (np. Node.js, Docker, XAMPP), który udaje produkcyjne API,
• skorzystać z service worker w przeglądarce, aby cache’ować wszystkie potrzebne żądania,
• wbudować w aplikację mechanizm „mock API”, który zwraca stałe odpowiedzi na typowe zapytania z demo.

Dla aplikacji mobilnych dobrym rozwiązaniem jest kompilacja specjalnej wersji „demo”, która:

• ma zaszyte w paczce pliki z danymi,

Projekt „pół‑offline”: minimum sieci, maksimum kontroli

Czasem pełne odcięcie od internetu jest zbyt radykalne. Potrzebujesz choć odrobiny „żywych” danych: aktualnego kursu, świeżej listy zgłoszeń, wyniku z prawdziwego sensora. Tu przydaje się tryb „pół‑offline”: demo działa całkowicie lokalnie, ale ma kontrolowane punkty kontaktu z siecią.

Klucz jest prosty: demo nie może się wyłożyć tylko dlatego, że nie ma odpowiedzi z sieci. Dlatego każdy krytyczny punkt komunikacji powinien mieć:

• domyślną odpowiedź z cache („gdy brak internetu, pokazujemy ostatni zapisany stan”),
• czas oczekiwania z góry (np. 1–2 sekundy, po czym ładowanie przerywane jest „trybem demo”),
• przełącznik trybu – flaga, która mówi aplikacji, że jest uruchomiona na wydarzeniu i ma zachowywać się zachowawczo.

Mit: „albo pełna produkcja, albo sztuczne demo”. Rzeczywistość: można pokazać realny system, ale w trybie awaryjnym, który nie zawiesza się na scenie tylko dlatego, że akurat 500 osób loguje się do tej samej sieci Wi‑Fi.

Projekt interfejsu, który nie zdradza kłopotów sieciowych

Duża część „magii stabilnego demo” dzieje się na poziomie UI. Gdy coś się ładuje, nie chcesz, żeby publiczność oglądała kręcące się kółko przez 10 sekund i twoją nerwową minę. Można temu zapobiec na etapie projektowania:

• preloader z limitem czasu – po 1–2 sekundach zawsze pokazuje wynik z cache lub wcześniej przygotowane dane,
• przejścia animowane – krótkie animacje między ekranami maskują fakt, że dane są lokalne i „wskakują” natychmiast,
• komunikaty błędów przetłumaczone na język demo – zamiast „Network error” pokazujesz: „Tryb demo: dane z ostatniej sesji”.

Jeśli wiesz, że pewien widok zwykle ładuje się 3–4 sekundy w produkcji, w wersji demo po prostu pokazujesz go po animacji przejścia, bez żadnego „ładowania”. Uczestnicy zapamiętają płynne doświadczenie, a nie to, czy dane przyszły z sieci czy z lokalnego pliku.

Ukryte przełączniki i krótyki dla zespołu

W trybie demo użyteczne są „tajne” mechanizmy, które prezenter zna na pamięć, a publiczność ich nie zauważa. Przykładowe rozwiązania:

• ukryte menu demo wywoływane gestem lub skrótem klawiaturowym (np. trzy kliknięcia w logo),
• przełącznik danych – możliwość zmiany scenariusza danych w locie (np. klient z branży A vs B),
• reset stanu – jedno kliknięcie/przycisk, który przywraca aplikację do „stanu startowego” przed kolejnym odwiedzającym stoisko.

Taki „panel demo” nie musi wyglądać pięknie. Ma być szybki i pewny. Pozwala naprawić drobne wpadki, np. ktoś przypadkiem usunął ważny rekord, bez konieczności przeładowywania całej aplikacji czy restartu urządzenia.

Wybór i przygotowanie sprzętu: telefon, tablet, laptop, dodatkowe „pudełka”

Jedno urządzenie do demo, reszta do pracy

Dużym źródłem kłopotów jest używanie tego samego laptopa do demo, maila, Slacka, buildów i wszystkiego innego. Aktualizacje, powiadomienia, brak miejsca na dysku – to scenariusz proszący się o problem. Znacznie bezpieczniej:

• mieć dedykowany sprzęt do demo (laptop/telefon/tablet),
• utrzymywać na nim minimalny zestaw aplikacji,
• zablokować automatyczne aktualizacje systemu i programów na czas wydarzenia.

Jeżeli budżet jest napięty, takim „dedykowanym sprzętem” może być po prostu stary, ale stabilny laptop lub telefon, który został wyczyszczony, zainstalowano na nim tylko to, co potrzebne do pokazu i przetestowano w identycznej konfiguracji jak na targach.

Laptop: stacja dowodzenia demo

Laptop zwykle jest elementem centralnym: prezentujesz na nim aplikację webową, podłączasz projektor, obsługujesz lokalny serwer. Przygotowując go, zadbaj o kilka rzeczy:

• czysty system – bez dziesiątek programów w tle, launcherów, widgetów,
• wyłączone wyskakujące powiadomienia (maile, komunikatory, aktualizacje),
• zainstalowane wszystkie zależności lokalne (serwer bazy danych, Docker, Node, runtimy),
• stałe ustawienie rozdzielczości, które dobrze wygląda zarówno na ekranie laptopa, jak i na projektorze/monitorze targowym.

Dobrym trikiem jest utworzenie osobnego konta użytkownika „DEMO” z automatycznym logowaniem. Po restarcie od razu lądujesz w przewidywalnym środowisku: ten sam pulpit, te same skróty, brak prywatnych plików.

Telefon i tablet: scenariusz „do ręki”

Gdy pokazujesz aplikację mobilną, urządzenie trafia do rąk widzów. Wtedy ryzyko rośnie: ktoś przypadkiem zsunie panel powiadomień, wyjdzie na pulpit, włączy systemowe menu gestami. Przygotuj urządzenie tak, aby ograniczyć ten chaos:

• skorzystaj z trybu „kiosk” lub „tylko jedna aplikacja” (Android, iOS mają takie funkcje),
• wyczyść ekran główny – tylko ikona demo, bez kuszących gier i aplikacji społecznościowych,
• wyłącz autokorektę i sugestie, jeśli w demo jest dużo wpisywania tekstu (mniej niespodziewanych „podpowiedzi”),
• zablokuj automatyczną rotację ekranu, jeśli interfejs jest projektowany tylko w jednej orientacji.

Przed wydarzeniem przećwicz kilka razy oddawanie telefonu w ręce kompletnie „zielonej” osoby – niech poklika, spróbuje wyjść z aplikacji, włączyć centrum sterowania. To szybki test, czy zabezpieczenia są wystarczające.

Monitory, projektory, telewizory: co może pójść nie tak

Tutaj pojawia się jeden z najpowszechniejszych mitów: „jak działa u mnie w biurze, to na targach też zadziała”. Rzeczywistość jest mniej łaskawa. Różne kable, przejściówki, rozszerzone pulpity, dziwne rozdzielczości. Kilka prostych reguł:

• zabierz swój komplet kabli i przejściówek (HDMI, USB‑C, DisplayPort, VGA jeśli organizator jest „retro”),
• ustaw jeden, sprawdzony tryb wyświetlania – najlepiej duplikowanie ekranu zamiast rozszerzania pulpitu,
• przetestuj demo w niższej rozdzielczości (np. 1280×720) – nie wszystkie telewizory targowe dobrze obsługują wysokie rozdzielczości,
• wyłącz wygaszacze, blokadę ekranu i usypianie komputera.

Jeśli masz osobne wideo promocyjne, trzymaj je jako oddzielny skrót na pulpicie, tak aby w każdej chwili można było przełączyć się z demo „na film” – to przyda się przy problemach sprzętowych.

Dodatkowe „pudełka”: routery, Raspberry Pi, jednostki IoT

Coraz częściej demo obejmuje fizyczne elementy: sterownik, sensor, mini‑komputer z aplikacją serwerową. Tutaj dochodzi nowa warstwa ryzyka – zasilanie, kable, zasięg. Kilka praktycznych wskazówek:

• jeśli używasz Raspberry Pi lub podobnej płytki, przygotuj kartę SD z gotowym obrazem systemu i konfiguracją „plug and play”,
• zapewnij osobne zasilanie (listwy zasilające, zapasowy zasilacz, powerbank do awaryjnego podtrzymania),
• wszystkie kable oznacz i skróć (opaski, taśma) – chaotyczna plątanina pod stołem to przepis na przypadkowe wypięcie czegoś w środku prezentacji,
• sprawdź, czy urządzenie startuje w autonomicznym trybie – po włączeniu zasilania powinno samo uruchomić aplikację serwerową / klienta.

Dobre praktyczne podejście: całe „pudełko” (router + Raspberry + sensor) traktować jak jedną czarną skrzynkę, którą da się podłączyć jednym kablem do prądu i jednym do laptopa, bez dodatkowej konfiguracji sieci na miejscu.

Jak uniezależnić się od Wi‑Fi organizatora (różne opcje łączności)

Własny router z kartą SIM: prywatna wyspa sieci

Najwygodniejszy sposób na odcięcie się od kaprysów Wi‑Fi organizatora to własny router LTE/5G (tzw. MiFi) z kartą SIM. Tworzysz swoją prywatną sieć, do której podłączasz tylko sprzęty demo. Dzięki temu:

• masz kontrolę nad nazwą sieci i hasłem,
• nikt z zewnątrz nie obciąża twojego łącza,
• nie musisz prosić organizatora o otwieranie portów i zgadywać, jakie są limity.

Mit: „mobilny internet jest za wolny na profesjonalne demo”. Rzeczywistość: większość dem na targach potrzebuje jedynie kilku lekkich zapytań HTTP. Jeśli demo się „dusi” na LTE, to prawdopodobnie jest źle zaprojektowane pod kątem transferu, a nie ofiarą łącza.

Hotspot z telefonu: plan B, nie plan A

Hotspot z telefonu przydaje się, ale traktuj go jako awaryjny backup, nie podstawowy kanał łączności. Powody są proste:

• telefon może się przegrzać i zredukować prędkość łącza,
• bateria spada błyskawicznie przy wielu podłączonych urządzeniach,
• przychodzące połączenia i SMS‑y potrafią zerwać hotspot.

Jeśli już używasz hotspotu, zadbaj o:

• tryb samolotowy + włączony tylko LTE/5G (brak połączeń głosowych),
• stałe podłączenie do zasilania,
• ograniczoną liczbę urządzeń podłączonych jednocześnie (na przykład tylko laptop demo).

Topologia sieci: wszystkie urządzenia „w jednym świecie”

Gdy demo wymaga kilku urządzeń (np. laptop + tablet + moduł IoT), upewnij się, że wszystkie są w tej samej sieci. Częsty błąd: laptop na Wi‑Fi organizatora, sensor na hotspot z telefonu, tablet na sieci publicznej – i debugowanie, czemu pakiety nie docierają.

Rozsądny układ:

• wszystkie urządzenia łączą się z twoim routerem LTE/5G albo
• tworzysz jedną sieć lokalną kablem Ethernet (switch + kable) i używasz internetu tylko jako opcjonalnego kanału.

Jeśli korzystasz z DNS‑ów, certyfikatów SSL, własnej domeny – zrób test bez internetu: czy laptop potrafi rozwiązać adresy i dogadać się z lokalnym serwerem po nazwie hosta. Na targach nie będzie czasu na walkę z /etc/hosts czy certyfikatami.

Ethernet tam, gdzie się da

Tam, gdzie organizator zapewnia kabel Ethernet zamiast lub oprócz Wi‑Fi, korzystaj z niego. Połączenie kablowe jest mniej podatne na przeciążenia i zakłócenia. Możliwy układ:

• Ethernet z gniazda organizatora do twojego routera/switcha,
• z routera/switcha kable do laptopa i ewentualnych innych urządzeń stacjonarnych,
• Wi‑Fi (z twojego routera) dla telefonów/tabletów demo.

Tak budujesz własną podsieć, a łącze od organizatora traktujesz tylko jako „wyjście na świat”.

Pomiary na miejscu i „mapa ryzyka” łączności

Jeśli to możliwe, odwiedź miejsce wydarzenia wcześniej, choćby dzień przed, i zrób proste pomiary:

• siła sygnału LTE/5G różnych operatorów przy twoim stoisku,
• przepustowość i opóźnienie na Wi‑Fi organizatora (speedtest, ping),
• czas odpowiedzi twojej produkcji, jeśli łączysz się „na żywo”.

Na tej podstawie ustal „mapę ryzyka”: jeśli mobilny internet jest słaby, kładziesz większy nacisk na tryb offline. Jeżeli Wi‑Fi organizatora działa tylko w niektórych godzinach – przełączasz się na własną sieć na czas pitcha lub pokazów na żywo.

Przygotowanie wersji demo produktu od strony technicznej

Oddzielne środowisko „demo” zamiast produkcji

Jedno z najrozsądniejszych posunięć: osobne środowisko demo, które technicznie jest kopią produkcji, ale:

Kontrolowane dane testowe zamiast „żywych”

Środowisko demo ma jedną kluczową przewagę nad produkcją: możesz kontrolować dane. Zamiast liczyć, że akurat trafi się ładne konto klienta czy ciekawy projekt, tworzysz zestaw przykładowych danych skrojonych pod twoją historię na scenie.

• przygotuj kilka kont użytkowników z różnymi poziomami uprawnień (np. administrator, typowy użytkownik, gość),
• dodaj konkretne, „bogate” rekordy – projekty z wieloma zadaniami, zamówienia z różnymi statusami, urządzenia z pełnymi odczytami sensorów,
• zadbaj o bezpieczne przykłady danych osobowych – fikcyjne nazwiska, firmy, adresy; nic z produkcji, nawet „anonimizowane”, jeśli nie masz stuprocentowej pewności, jak to zrobiono,
• wprowadź stabilne identyfikatory (ID, numery zamówień), które możesz z góry wpisać w scenariusz prezentacji i notatki.

Mit bywa taki: „pokażmy prawdziwe dane, będą ciekawsze”. W praktyce kończy się to pokazywaniem pustych kont, dziwnych duplikatów, a czasem wrażliwych informacji. Dane demo masz pod pełną kontrolą – nie zaskoczą cię w najgorszym możliwym momencie.

Seedowanie i reset stanu demo jednym przyciskiem

Po kilku godzinach targów środowisko demo często jest „zajechane”: coś skasowane, coś przeklikane, proces utknął w połowie. Bez szybkiego resetu w którymś momencie demonstrujesz już nie produkt, tylko bałagan po poprzednich rozmowach.

Najpraktyczniejsze rozwiązanie to mechanizm seedowania danych i resetu stanu:

• skrypt lub komenda, która czyści bazę i wgrywa świeży zestaw danych testowych,
• możliwość odpalenia tego procesu lokalnie, bez internetu (np. docker compose z krokami inicjalizacji),
• „przycisk paniki”: np. specjalny endpoint zabezpieczony hasłem, który odtwarza predefiniowany stan demo.

Dobrze, jeśli taki reset trwa minuty, a nie godziny. Na targach przerwa na kawę to często jedyne okno czasowe na „odświeżenie świata”.

Tryb offline w aplikacji webowej: cache, fallbacki, kolejka zdarzeń

Aplikacja webowa też może mieć sensowny tryb offline, szczególnie jeśli główne operacje to przeglądanie danych i lokalne interakcje. Kluczowe elementy:

• cache zasobów statycznych – Service Worker + Cache API, żeby aplikacja ładowała się bez sieci,
• lokalne przechowywanie danych (IndexedDB, LocalStorage) na potrzeby podstawowych widoków,
• fallbacki dla requestów – gdy API jest niedostępne, sensowny komunikat i dane z cache zamiast „kręcącego się kółka”,
• kolejka zdarzeń (np. w IndexedDB): akcje użytkownika zapisujesz lokalnie i wysyłasz po odzyskaniu łączności.

Jeśli nie da się w pełni zaimplementować trybu offline, wybierz konkretną ścieżkę w aplikacji, która jest „bezpieczna” bez sieci (np. demo raportów na danych lokalnych) i oprzyj o nią scenariusz targowy.

Aplikacja desktopowa / lokalny serwer: demo „na własnym silniku”

Przy produktach SaaS częsta strategia na targi to lokalna kopia backendu na laptopie lub mini‑serwerze (Raspberry Pi, Intel NUC). Front łączy się wtedy do http://localhost lub prywatnego IP w twojej sieci.

Taki układ ma kilka plusów:

• pełna kontrola nad opóźnieniem i stabilnością,
• brak zależności od DNS, certyfikatów produkcyjnych, bramek płatności,
• możliwość przygotowania specjalnych endpointów demo symulujących różne scenariusze.

Trzeba jednak pilnować prostoty konfiguracji. Idealnie, jeśli na potrzeby demo możesz:

• uruchomić całość jednym poleceniem (np. docker compose up lub prostym skryptem),
• mieć zafiksowane wersje bibliotek i zależności (obraz Dockera, snapshot środowiska),
• wozić ze sobą zapasową kopię: drugi pendrive z tym samym obrazem, drugi laptop z gotową instancją.

Mockowanie integracji z systemami zewnętrznymi

Integracje to klasyczne źródło wpadek: bramka płatności, zewnętrzne API, ERP klienta, system logistyczny. Na targach nie masz żadnej kontroli nad ich dostępnością, limitami czy danymi.

Rozsądniej jest przygotować mocki lub stuby kluczowych integracji:

• lokalne serwisy, które udają odpowiedzi API produkcyjnego (np. mały serwer Node/Flask z predefiniowanymi odpowiedziami),
• specjalne flagi konfiguracyjne (DEMO_MODE=true), które przełączają aplikację z prawdziwych integracji na mocki,
• symulacje różnych stanów: sukces, błąd, opóźnienie – tak żeby można było pokazać obsługę błędów bez liczenia na awarię w czasie rzeczywistym.

Mit: „prawdziwa integracja zrobi większe wrażenie niż symulacja”. W rzeczywistości większe wrażenie robi płynny, przewidywalny pokaz niż siedzenie z publicznością i czekanie, aż „coś odpowie”.

Feature flagi i „tryby pokazu”

Wersja demo często potrzebuje innych ustawień niż produkcja: skróconych timeoutów, pominięcia części kroków, wymuszonych stanów. Zamiast kompilować osobny build „na targi”, wygodniej wprowadzić flagi funkcji.

Przydatne mogą być zwłaszcza:

• pomijanie długich kroków (np. analizy trwające normalnie kilka minut),
• wymuszone dane w niektórych widokach (np. „zawsze pokazuj pełen raport, nawet jeśli dane są niekompletne”),
• ukrycie niedokończonych funkcji, do których łatwo przypadkiem trafić klikaniem „na chybił trafił”.

Dobrze nazwana flaga (DEMO_FAST_MODE, DEMO_FAKE_PAYMENTS) działa też jak dokumentacja dla zespołu: każdy od razu wie, co się dzieje pod spodem i dlaczego demo zachowuje się inaczej niż produkcja.

Stabilne wersje zamiast „najświeższego developa”

Jest pokusa, żeby na targach pokazać totalnie najnowszą wersję z gałęzi deweloperskiej, bo „tam jest ta świetna nowa funkcja”. Problem w tym, że ta wersja zwykle nie przeszła pełnego cyklu testów i potrafi się zachować nieprzewidywalnie.

Bezpieczniejsza strategia:

• oprzyj demo na tagowanej wersji (release), która działa stabilnie,
• nowe funkcje pokazuj tylko wtedy, gdy są faktycznie ukończone i przetestowane,
• jeśli już musisz coś „na świeżo”, miej drugi scenariusz prezentacji, w którym całkowicie omijasz tę funkcję przy pierwszym problemie.

Z perspektywy widza bardziej imponuje solidne, przewidywalne narzędzie niż pokaz „early access”, który wymaga tłumaczeń przy co drugim kliknięciu.

Minimalne logowanie i diagnostyka „na scenie”

Wersja demo potrzebuje innego logowania niż produkcja. Z jednej strony, chcesz móc szybko stwierdzić, co się dzieje, gdy demo się przytnie. Z drugiej – nie możesz zasypać systemu gigabajtami logów ani wyświetlać poufnych informacji przy publiczności.

Przydatne podejście:

• włącz zwięzłe logi techniczne (poziom info/warn) zapisywane lokalnie,
• dodaj „panel statusu demo” – prosty widok, gdzie widać np. stan połączeń, ostatnie zapytania, status backendu (dostępny/Offline),
• logi wyszczególniaj na osobnym ekranie lub w konsoli – nigdy w głównym UI, który widzi publiczność.

Takie mini‑narzędzia diagnostyczne często ratują sytuację: widzowie widzą, że coś się na moment zawiesiło, a ty w 5 sekund decydujesz, czy restartować demo, czy po prostu przeskoczyć fragment.

Przygotowanie scenariuszy: „złota ścieżka” i plan awaryjny

Nawet najlepiej przygotowane technicznie demo wymaga scenariusza. Chaos „a teraz trochę poklikamy” szybko prowadzi do ślepych zaułków w UI, ekranów ładowania i sytuacji „chwileczkę, muszę się cofnąć”.

Dobrze jest mieć:

• złotą ścieżkę – główny scenariusz prezentacji opisany krok po kroku (ekran, akcja, kluczowy komunikat),
• ścieżkę skróconą na 2–3 minuty – gdy masz mało czasu podczas pitcha lub ktoś podchodzi na szybką prezentację,
• plan B: odpowiednik „trybu demonstracyjnego”, np. gotowe nagranie ekranu lub animacja kliknięć, na które możesz się przełączyć, jeśli coś przestanie działać.

Mit: „im bardziej spontaniczne demo, tym bardziej autentyczne”. W realu spontaniczność bez przygotowania kończy się błądzeniem po interfejsie. Dobrze przygotowany scenariusz wcale nie musi brzmieć sztucznie – po prostu usuwa zbędne zakręty.

Checklisty przed wyjazdem i na stoisku

Na koniec pracy nad wersją demo przydaje się bardzo przyziemne narzędzie: checklista. Jedna przed wyjazdem, druga już na stoisku. To twardy bezpiecznik na ludzkie zapominalstwo.

Przykładowe punkty przed wyjazdem:

• czy środowisko demo działa bez internetu lub z własnym routerem,
• czy dane testowe są świeże, spójne i zgodne ze scenariuszem,
• czy backup (drugi laptop/pamięć z obrazem) jest faktycznie sprawdzony, a nie tylko „spakowany”.

Na stoisku:

• czy wszystkie urządzenia widzą się w tej samej sieci,
• czy wersje aplikacji na laptopie, tablecie i telefonie są zgodne,
• czy „przycisk resetu demo” działa i czy wiesz, ile trwa odświeżenie.

To nie jest fanaberia. Po kilku godzinach hałasu, rozmów i improwizacji nawet najbardziej ogarnięta osoba zaczyna gubić szczegóły. Dobra checklista oszczędza nerwów i ratuje niejedno demo, zanim jeszcze coś zdąży się zepsuć przy publiczności.

Najczęściej zadawane pytania (FAQ)

Jak przygotować demo produktu na targi, żeby nie było zależne od Wi‑Fi?

Najprościej: zaplanuj demo tak, jakby internetu miało nie być w ogóle. Kluczowe ekrany i dane (lista produktów, przykładowe zamówienia, raporty) wgraj lokalnie do aplikacji lub do lekkiej bazy na urządzeniu. Logowanie zastąp kontem demo automatycznie zalogowanym przy starcie, a integracje zewnętrzne – zasymulowanymi danymi.

Dobrym wzorcem jest tryb „offline demo” w produkcie: osobna konfiguracja lub build, który działa na lokalnym zestawie danych i nie próbuje łączyć się z serwerem, gdy nie musi. Mit brzmi: „przecież demo musi być na żywym systemie, inaczej to ściema”. Rzeczywistość: celem demo jest pokazanie wartości produktu, a nie testowanie stabilności cudzej sieci.

Dlaczego Wi‑Fi na targach i hackathonach tak często nie działa stabilnie?

Powód jest prozaiczny: zbyt wiele urządzeń w jednym miejscu. Setki telefonów, laptopów, telewizorów i IoT walczą o ten sam eter i to samo łącze. Do tego dochodzą ściany, metalowe konstrukcje stoisk, kiepsko skonfigurowane access pointy, firewalle blokujące nietypowe porty czy WebSockety.

Często sieć „formalnie jest”, ale w praktyce ping skacze, pakiety się gubią, a każde żądanie HTTP trwa kilka sekund. Organizator odpowiada za to, żeby „coś działało dla większości”, nie za to, że twoje konkretne API zadziała akurat w trakcie twojego pitchu.

Czy mogę zaufać Wi‑Fi zapewnianemu przez organizatora wydarzenia?

Możesz je traktować wyłącznie jako miły bonus, nigdy jako fundament kluczowego demo. Organizator może zmienić hasło w dniu wydarzenia, przełączyć konfigurację, ograniczyć liczbę urządzeń albo po prostu nie mieć ludzi, którzy pomogą ci debugować połączenie tuż przed wyjściem na scenę.

Mit: „organizator napisał, że będzie szybkie Wi‑Fi, więc jestem bezpieczny”. Rzeczywistość: nikt przy zdrowych zmysłach nie opiera sprzedaży czy pitchu inwestorskiego na infrastrukturze, na którą nie ma żadnego wpływu. Profesjonaliści zakładają, że Wi‑Fi padnie w najgorszym możliwym momencie – i projektują demo tak, żeby mimo tego wyglądało świetnie.

Jakie funkcje produktu koniecznie pokazać w demie, a co lepiej odpuścić?

Punkt wyjścia to jedno proste zdanie: co odbiorca ma zapamiętać po 3–5 minutach. Jeśli celem jest „jednym kliknięciem generujemy raport księgowy”, to pokazujesz drogę do tego kliknięcia i efekt końcowy, a nie wszystkie ustawienia, moduły i integracje.

Bezpieczna struktura to: krótki start (ewentualnie logowanie lub od razu konto demo), jedna główna ścieżka użytkownika, „moment wow” na końcu. Im mniej ekranów, tym mniejsze ryzyko, że któryś z nich zawiesi się, nie dociągnie danych lub pokaże nieoczekiwany błąd. Nadmiar funkcji w demie nie robi wrażenia – za to zwiększa szansę na spektakularną wpadkę.

Jak technicznie przygotować aplikację webową lub mobilną do pracy offline podczas prezentacji?

Po pierwsze, zmapuj wszystkie miejsca, gdzie aplikacja woła serwer: logowanie, listy, zapisy, integracje, powiadomienia na żywo. Następnie dla każdego kroku zdecyduj, czy na potrzeby demo możesz to zastąpić lokalnymi danymi albo prostą symulacją. Często wystarczy sztywny plik JSON z przykładowymi danymi lub lekka baza SQLite na urządzeniu.

Po drugie, przygotuj osobny build lub tryb „demo”, w którym:

• domyślnie zalogowane jest konto demonstracyjne,
• dane czytane są najpierw lokalnie, a dopiero potem (opcjonalnie) z sieci,
• w razie braku internetu aplikacja nie wyświetla krytycznych błędów, tylko spokojnie korzysta z przygotowanych wcześniej danych.

To nadal „prawdziwy produkt”, tylko w konfiguracji zoptymalizowanej pod warunki targowe.

Co zrobić, jeśli mimo przygotowań internet padnie w trakcie mojego pitchu?

Plan B powinien być gotowy, zanim wyjdziesz na scenę. Minimum to:

• nagranie krótkiego wideo z idealnie działającą ścieżką demo,
• kilka slajdów pokazujących kluczowe ekrany i efekt końcowy,
• jasna narracja, która pozwala opowiedzieć historię nawet bez klikania na żywo.

W praktyce, jeśli podczas live-demo coś się zawiesi, spokojnie przełączasz się na wideo lub slajdy i kontynuujesz opowieść, zamiast nerwowo klikać i przepraszać.

Mit: „jak demo padnie, to już po wszystkim”. Rzeczywistość: ludzie są w stanie zaakceptować problemy techniczne, jeśli widzą, że masz kontrolę nad sytuacją i plan awaryjny. To lepszy sygnał dla inwestora niż chaotyczna panika nad niedziałającym Wi‑Fi.

Jak rozdzielić role w zespole podczas prezentacji demo na scenie lub stoisku?

Najlepiej, gdy jedna osoba skupia się na mówieniu, a druga na „operatorce” – czyli klikaniu zgodnie ze scenariuszem, pilnowaniu sprzętu, przełączaniu widoków. Dzięki temu prezenter może utrzymać kontakt z publicznością, a ktoś inny dba o techniczną stronę występu.

Przed wydarzeniem spisz konkretny scenariusz: kto trzyma który sprzęt, kto podłącza się do rzutnika, na jakim urządzeniu odpalasz demo, co się dzieje, jeśli rzutnik odmówi współpracy. Kilka suchych prób z odliczaniem czasu robi ogromną różnicę – na scenie nie zastanawiasz się „co teraz kliknąć?”, tylko odgrywasz dobrze znaną sekwencję.

Co warto zapamiętać

• Stabilne demo nie może zależeć od Wi‑Fi na wydarzeniu – duże zagęszczenie urządzeń, zakłócenia i losowa konfiguracja sieci sprawiają, że nawet „mocne łącze” często w kluczowym momencie zwalnia lub całkiem pada.
• Mit, że „organizator zapewnia szybkie Wi‑Fi, więc wystarczy się podłączyć”, zderza się z rzeczywistością: jedna sieć dla wszystkich, nagłe zmiany haseł, brak wsparcia technicznego pod twoje API i porty – to wszystko leży poza twoją kontrolą.
• Interaktywne demo produktu jest znacznie bardziej ryzykowne niż zwykła prezentacja slajdów, bo każde kliknięcie może wymagać połączenia z backendem, zewnętrznym API czy płatnościami; jedno przycięcie internetu niszczy cały efekt.
• Porażka demówki przez Wi‑Fi uderza w wiarygodność zespołu: zamiast obrazu „ogarniętej technologii” widz dostaje kółko ładowania, nerwowe tłumaczenia i pytanie, czy skoro demo nie działa, to jak zadziała produkcja.
• Profesjonalne demo przygotowuje się jak spektakl: jasny scenariusz krok po kroku, sprawdzone „rekwizyty” (sprzęt, konta, dane), próby generalne oraz plan B (tryb offline, nagranie wideo, slajdy), który ratuje sytuację, gdy sieć odmówi posłuszeństwa.
• Punktem wyjścia jest nie technologia, tylko jasny cel: co odbiorca ma zapamiętać po 3–5 minutach; dopiero z tego wynika, które funkcje pokazać, żeby zminimalizować liczbę kroków, zależności od sieci i potencjalnych punktów awarii.