Od hackathonu do produktu: jak zespół buduje start-up edukacyjny

Od hackathonu do produktu – realna droga, a nie weekendowa magia

Hackathon ma reputację miejsca, gdzie w 48 godzin powstają „rewolucyjne” pomysły, a po weekendzie wszystko wraca do normalności. W przypadku start-upu edukacyjnego taki scenariusz kończy się zwykle folderem z prezentacją i repozytorium kodu, do którego nikt nie zagląda. Różnica między jednorazową akcją a początkiem realnego produktu polega na jednym: zespół traktuje hackathon nie jako finał, ale jako początek procesu.

Start-up edukacyjny rządzi się dodatkowymi prawami. Trzeba pogodzić technologię, dydaktykę, realia szkoły lub uczelni, a do tego płatników (rodziców, instytucje, firmy). Od hackathonu do działającego produktu edukacyjnego droga jest trudniejsza niż przy typowej aplikacji B2C, ale przy odpowiednim podejściu ten intensywny weekend może stać się silnym fundamentem.

Punktem wyjścia nie jest ani kod, ani logo, ani efektowny pitch, lecz jasna decyzja zespołu: „idziemy dalej”. Dopiero po niej pojawia się sens, by inwestować czas w dopracowanie pomysłu, walidacje z nauczycielami, pierwszych pilotów i rozwój produktu, który cokolwiek zmienia w edukacji, a nie tylko wygląda dobrze na slajdzie.

Wybór pomysłu na hackathonie: czym różni się edtech od „zwykłej” apki

Jak filtrować pomysły już na etapie hackathonu

Na hackathonie wszystko wydaje się możliwe, bo ogranicza nas głównie czas. W praktyce nie każdy pomysł nadaje się do rozwijania jako pełnoprawny start-up edukacyjny. Przed końcem wydarzenia opłaca się zadać zespołowi kilka twardych pytań:

• Kto ma realny problem? Konkretny nauczyciel, dyrektor, rodzic, student, dział HR w firmie? Im bardziej namacalna grupa, tym lepiej.
• Czy użytkownik ma motywację, by zmienić swoje zachowanie? Nauczyciel ma mało czasu, uczeń często unika dodatkowych zadań, a rodzic jest zalany ofertami. Produkt musi dotykać silnej motywacji (mniej papierologii, lepsze wyniki, spokój, oszczędność czasu).
• Czy ktoś mógłby za to kiedyś zapłacić? Nawet jeśli model jest odległy, ważne, by potencjalny płatnik istniał: szkoła, rodzic, uczelnia, firma, grantodawca.
• Czy da się zrobić pierwszą wersję w 4–8 tygodni po hackathonie? Jeśli potrzebujesz roku badań naukowych albo akceptacji ministerstwa, to raczej nie jest materiał na start-up na tym etapie.

Filtrowanie pomysłów w trakcie hackathonu bywa trudne, bo panuje atmosfera „wszystko jest super”. Warto mieć w zespole choć jedną osobę, która zadaje niewygodne, ale kluczowe pytania: kto, za co, kiedy, jak często użyje tego rozwiązania i co to realnie zmienia w jego życiu.

Specyfika pomysłów edukacyjnych: czas, motywacja i struktury

Edukacja to środowisko silnie ustrukturyzowane. Nauczyciele pracują w określonych godzinach, szkoły mają swoje procedury, uczelnie – senaty i komisje, a rodzice – ograniczony budżet. Dobry pomysł edtechowy musi się w tę strukturę wpasować, a nie próbować ją od razu zburzyć.

Potencjalne „miny”, na które natyka się wielu zwycięzców hackathonów edukacyjnych:

• Cykl roku szkolnego – wdrażanie nowego rozwiązania w maju lub listopadzie jest dużo trudniejsze niż w sierpniu/wrześniu czy styczniu.
• Obciążenie nauczycieli – nawet świetne narzędzie, które wymaga dodatkowych 30 minut dziennie, często jest skazane na porażkę.
• Sprzęt i dostęp do internetu – szkoły i uczelnie dysponują różnym parkiem maszynowym; aplikacja działająca tylko na najnowszych urządzeniach odpada na starcie.
• Bezpieczeństwo danych uczniów – temat RODO i ochrony danych osobowych jest w edukacji dużo wrażliwszy niż w zwykłej aplikacji konsumenckiej.

Jeśli pomysł hackathonowy nie uwzględnia choć części tych ograniczeń, warto go zmodyfikować jeszcze w trakcie pracy nad prototypem. Czasem niewielka zmiana – np. z pełnej platformy na prosty plug-in do już używanego systemu – robi różnicę między „fajnym demo” a realnym produktem.

Prosta matryca oceny pomysłu zaraz po hackathonie

Po zakończeniu wydarzenia dobrze jest przeprowadzić szybką, szczerą ocenę pomysłu. Pomaga w tym prosta matryca:

Wspólne wypełnienie takiej matrycy zmusza do precyzji i pomaga uniknąć sytuacji, w której ktoś ciągnie pomysł z przyzwyczajenia, a reszta zespołu jest już myślami gdzie indziej.

Zespół po hackathonie: jak zamienić grupę „na weekend” w realny team

Ustalenie ról i odpowiedzialności po emocjach hackathonu

W trakcie hackathonu role często są płynne: wszyscy trochę projektują, trochę kodują, ktoś „coś ogarnia z prezentacją”. Po wydarzeniu ten chaos zaczyna przeszkadzać. Jeśli zespół chce iść dalej, musi przejść z trybu „wszyscy robią wszystko” do jasno zdefiniowanych ról.

W typowym start-upie edukacyjnym po hackathonie pojawiają się co najmniej cztery obszary:

• Produkt i użytkownik – osoba odpowiedzialna za zrozumienie potrzeb nauczycieli/uczniów, prowadzenie rozmów, zbieranie feedbacku.
• Technologia – jedna lub więcej osób, które realnie dowożą kod lub konfigurację narzędzia (np. bezkodowe rozwiązania).
• Biznes i sprzedaż – ktoś, kto myśli o cenie, modelu biznesowym i ma odwagę zadzwonić do szkoły czy firmy.
• Operacje i formalności – osoba pilnująca spraw formalnych, prostych procesów, dokumentacji, grantów.

Na starcie te role mogą się częściowo nakładać, ale dobrze, by każdy wiedział, za co czuje się odpowiedzialny. Najprostszy sposób: krótka sesja online, w której każdy odpowiada na pytanie: „Za którą część projektu jestem gotów odpowiadać przez najbliższe 3 miesiące?”.

Motywacja i zaangażowanie: kto naprawdę chce budować start-up

Hackathon to adrenalina i nagrody. Budowa start-upu edukacyjnego to często tygodnie bez spektakularnych rezultatów, rozmowy z trudnymi partnerami i praca po godzinach. Różnica w motywacji wychodzi na wierzch bardzo szybko.

Żeby uniknąć nieporozumień, zespół powinien szczerze omówić:

• Dostępny czas – czy ktoś może poświęcić 5, a ktoś 20 godzin tygodniowo? Lepiej to nazwać, niż zakładać.
• Horyzont czasowy – czy planujecie pracować nad tym minimum 3–6 miesięcy, czy raczej „zobaczy się za tydzień”?
• Oczekiwania finansowe – nikt nie wie, czy start-up zarobi, ale warto ustalić, czy ktoś liczy na szybki etat czy traktuje to jako eksperyment.

Prosty dokument w stylu „mini-karty projektu” (1–2 strony) potrafi uratować relacje w zespole. Można w nim zapisać: cel na 3 miesiące, deklarowany wkład czasowy, proste zasady podejmowania decyzji oraz wstępną wizję podziału udziałów (nawet jeśli formalnie jeszcze ich nie ma).

Podział udziałów i formalności – bez mitów i niedomówień

Start-up edukacyjny to nadal biznes, a więc w którymś momencie pojawi się temat udziałów. Najgorszy scenariusz: rozmawia się o tym dopiero przy pierwszych pieniądzach. Dużo zdrowszy wariant: wstępne ustalenia pojawiają się wcześnie, nawet jeśli są jeszcze „miękkie”.

Do rozmowy o podziale udziałów przydają się trzy zasady:

1. Docenienie wkładu „tu i teraz” – kto faktycznie poświęca czas po hackathonie?
2. Znaczenie kluczowych kompetencji – brak programisty lub osoby od sprzedaży może zatrzymać projekt; ten wkład jest inny niż sporadyczne doradztwo.
3. Zasada vestingu – udziały „uwalniane” w czasie w zamian za realną pracę, a nie jednorazowy wkład na hackathonie.

Wiele zespołów na początku zapisuje ustalenia w prostym dokumencie (np. „letter of intent”), a dopiero przy rejestracji spółki przekłada to na formalne umowy. Sam fakt przeprowadzenia takiej rozmowy jest ważniejszy niż idealne proporcje udziałów.

Od prototypu hackathonowego do pierwszego MVP

Czym różni się hackathonowy prototyp od MVP w edtechu

Prototyp z hackathonu jest zwykle zbudowany na jedno demo: działa w konkretnym scenariuszu, przy określonych danych, na wybranym urządzeniu. MVP (Minimum Viable Product) to produkt, który ktoś z zewnątrz może sam użyć do rozwiązania swojego realnego problemu, choćby w bardzo ograniczonym zakresie.

W edukacji ta różnica jest szczególnie widoczna. Nauczyciel nie będzie kliknął w 10 przycisków konfiguracyjnych, jeśli ma 5 minut przerwy między lekcjami. Uczeń odinstaluje aplikację, która wymaga za dużo rejestracji i potwierdzeń. MVP musi być:

• Stabilne w jednym kluczowym scenariuszu – np. wygenerowanie i wysłanie jednego zestawu ćwiczeń, zapisanie się na jedno wydarzenie, przeprowadzenie jednej krótkiej lekcji zdalnej.
• Samodzielne dla użytkownika – ktoś spoza zespołu jest w stanie z niego skorzystać bez waszej obecności na czacie.
• Ograniczone funkcjonalnie – zamiast próbować obsłużyć wszystkie typy szkół i przedmiotów, skupiacie się np. tylko na matematyce w klasach 4–6.

Przejście od prototypu do MVP wymaga odcięcia pomysłów, które pojawiły się w euforii hackathonu. Dobrą praktyką jest spisanie listy „fajnych, ale później” i odłożenie jej do osobnego dokumentu, żeby nie kusiło dorzucanie wszystkiego naraz.

Plan technologiczny na 4–8 tygodni: minimalny, ale realistyczny

Zespół techniczny powinien określić, co dokładnie zostanie zrobione w pierwszych tygodniach po hackathonie. Zamiast abstrakcyjnych „iteracji” przydaje się prosty plan w stylu:

• tydzień 1–2 – porządki w kodzie z hackathonu, konfiguracja środowiska, wybór narzędzi (repozytorium, system zadań), usunięcie „twardych” danych demo;
• tydzień 3–4 – implementacja kluczowego przepływu użytkownika (np. rejestracja nauczyciela, utworzenie klasy, wysłanie jednego zadania);
• tydzień 5–6 – poprawki po pierwszych testach, dopracowanie interfejsu, prosta analityka (jak często loguje się użytkownik, co klika);
• tydzień 7–8 – przygotowanie do pilota: stworzenie prostych materiałów (instrukcje, krótkie wideo, opis).

W edukacji dobrze sprawdza się podejście, w którym funkcje „uczniowskie” są budowane po tym, jak dopracuje się część „nauczycielską” lub „administracyjną”. To właśnie nauczyciele i administratorzy decydują, czy narzędzie wejdzie do klasy, więc ich ścieżka powinna być pierwsza i najbardziej dopieszczona.

Bezpieczeństwo i prywatność: element obowiązkowy, nie „na później”

Produkty edukacyjne niemal zawsze dotykają danych wrażliwych: imion i nazwisk uczniów, wyników testów, czasem danych zdrowotnych czy socjalnych. Nawet w fazie MVP trzeba zadbać o kilka absolutnych podstaw:

• Brak prawdziwych danych uczniów w kodzie – wszystko, co pokazujecie na demo, powinno opierać się na fikcyjnych profilach.
• Bezpieczne logowanie – unikajcie wysyłania haseł w mailu w czystej postaci; nawet proste resetowanie hasła z tokenem jest lepsze niż prowizoryczne rozwiązania.
• Świadoma zgoda na pilota – nauczyciel, dyrektor lub rodzic powinni wiedzieć, że uczestniczą w testach nowego narzędzia i co się dzieje z danymi.

Pierwszy pilotaż w szkole lub firmie: jak testować, żeby naprawdę się uczyć

MVP nabiera sensu dopiero wtedy, gdy trafi do prawdziwego środowiska. W edtechu oznacza to przynajmniej jedną szkołę, grupę nauczycieli lub dział L&D w firmie. Zamiast „wrzucać link na Facebooka”, lepiej przeprowadzić kontrolowany pilotaż, nad którym da się zapanować.

Najprostszy model pilotażu to:

• 1–2 nauczycieli „leadów” (lub 1 osoba z HR/L&D), którzy są autentycznie ciekawi nowego rozwiązania;
• jedna klasa / jedna grupa, a nie cała szkoła – mniejsza skala to mniejsze ryzyko chaosu;
• konkretny okres czasu – np. 4 tygodnie regularnego używania narzędzia; pilotaże „bez końca” rozmywają się i trudno wyciągnąć z nich wnioski.

Przed startem warto wspólnie z nauczycielem spisać 3–5 oczekiwanych efektów, nawet bardzo prostych, np.: „uczniowie częściej oddają prace domowe”, „oszczędzam 20 minut tygodniowo na sprawdzaniu”, „mam podgląd, kto nie zrobił zadania”. Te oczekiwania staną się później punktem odniesienia do decyzji: iść dalej czy zmienić kierunek.

Jak zbierać feedback od nauczycieli i uczniów

Bez świadomego zbierania informacji MVP zamienia się w eksperyment „na czuja”. Feedback nie musi oznaczać długich ankiet – w środowisku edukacyjnym lepiej działają krótkie, powtarzalne rytuały.

Sprawdza się połączenie trzech źródeł informacji:

• Rozmowy 1:1 – 20–30 minut z nauczycielem po pierwszym tygodniu i pod koniec pilotażu. Zestaw stałych pytań (np. co było najłatwiejsze, co najbardziej wkurzające, kiedy prawie zrezygnowałaś/eś?) i notatki w jednym dokumencie dla całego zespołu.
• Krótkie ankiety dla uczniów – 3–5 pytań, najlepiej na jednym ekranie. Mogą być w stylu: „czy użyłbyś tego narzędzia ponownie?”, „co było najbardziej mylące?”. Uczniowie często bez ogródek pokazują, gdzie UX zupełnie nie działa.
• Dane z produktu – prosta analityka: ilu użytkowników założyło konto, ilu wróciło drugi raz, które ekrany mają najwięcej porzuceń. Nie trzeba do tego od razu zaawansowanych narzędzi – ważna jest powtarzalność obserwacji.

W jednym z pilotaży narzędzia do quizów online większość nauczycieli deklarowała zadowolenie. Dopiero spojrzenie na logi pokazało, że połowa z nich korzystała z produktu tylko raz, bo proces tworzenia pytań był za długi. To przykład, że deklaracje i dane trzeba zestawiać ze sobą.

Model biznesowy w start-upie edukacyjnym: komu naprawdę sprzedajesz

Użytkownik a płatnik: dwa różne światy

W edtechu występuje typowy konflikt: kto inny używa produktu, a kto inny za niego płaci. Użytkownikiem jest nauczyciel lub uczeń, ale budżet kontroluje dyrektor szkoły, organ prowadzący, dział zakupów w firmie albo rodzic.

Przy projektowaniu modelu biznesowego trzeba odpowiedzieć na kilka prostych, ale kluczowych pytań:

• czy naciskacie na sprzedaż do szkół/instytucji, czy raczej na indywidualnych rodziców/uczniów?
• kto robi ostatni „klik” zakupowy – dyrektor, nauczyciel, rodzic, HR?
• czy kupujący widzi mierzalną korzyść (oszczędność czasu, lepsze wyniki, spełnienie wymogów prawnych)?

Przykładowo: platforma z krótkimi kursami dla nauczycieli może być sprzedawana jako abonament dla całej szkoły (argument: rozwój kadry i zgodność z wymaganiami awansu zawodowego) albo jako tani dostęp indywidualny (argument: szybkie, praktyczne materiały). Produkt jest ten sam, ale komunikacja i proces sprzedaży – zupełnie inne.

Proste modele przychodów na start

Zespół po hackathonie nie musi od razu budować złożonych cenników. Na pierwsze 6–12 miesięcy wystarczą 1–2 warianty, które da się wytłumaczyć w jednym zdaniu. Najczęściej sprawdzają się:

• Abonament miesięczny/roczny – per nauczyciel, per klasa lub per szkoła. Łatwy do wdrożenia, ale wymaga zadbania o odnowienia (automatyczne płatności, przypomnienia).
• Opłata per kurs / per grupa – sensowna, jeśli macie wyraźnie odseparowane moduły (np. kurs maturalny, kurs z programowania dla klas 7–8).
• Licencja instytucjonalna – jednorazowa większa opłata dla szkoły lub firmy na określony czas (np. rok), z limitem użytkowników. Ułatwia rozmowę z dyrektorem, bo nie trzeba rozbijać budżetu na pojedynczych nauczycieli.

Na tym etapie lepiej unikać bardzo rozdrobnionych planów typu „plan basic, pro, premium, enterprise”, jeśli za nimi nie stoi realnie inny sposób używania produktu. Im mniej opcji, tym łatwiej sprzedawać i zbierać dane, co faktycznie działa.

Sprzedaż bez działu sprzedaży: pierwsze rozmowy z klientami

We wczesnym start-upie sprzedaż robi zespół założycielski. Nie trzeba „znać się na sprzedaży”, żeby porozmawiać z dyrektorem czy liderką zespołu nauczycieli – trzeba jednak wyjść poza koleżanki i kolegów ze swojej bańki.

Podstawowy rytm może wyglądać tak:

• lista 20–30 potencjalnych szkół/organizacji, do których macie jakiekolwiek „ciepłe wejście” (znajomy nauczyciel, absolwent, dawny współpracownik);
• prosty, krótki mail z konkretną propozycją pilotażu (2–3 zdania opisu, co rozwiązujecie, i jasne „co dalej”, np. 20-minutowa rozmowa);
• prowadzony w jednym miejscu rejestr rozmów, odpowiedzi, obiekcji i ustaleń – arkusz kalkulacyjny wystarczy, ważna jest systematyczność.

Wielu założycieli „chowa się” za dopracowywaniem produktu, bo rozmowy sprzedażowe bywają stresujące. Tymczasem to właśnie reakcje pierwszych klientów najlepiej pokazują, czy pomysł ma ekonomiczny sens. Jeśli nikt nie jest gotów poświęcić 20 minut na rozmowę, trudno liczyć na opłacenie abonamentu.

Partnerstwo ze szkołami i instytucjami: jak uniknąć paraliżu decyzyjnego

Jak wybierać pierwszych partnerów pilotażowych

Nie każda szkoła czy organizacja będzie dobrym partnerem na start. Zespół, który decyduje się na „największe liceum w mieście” jako pierwszego klienta, często utknie w procedurach. Dużo bezpieczniej zacząć od środowisk, które:

• mają kulturę eksperymentowania – szkoły ćwiczeniowe, placówki biorące udział w projektach unijnych, organizacje pozarządowe prowadzące zajęcia edukacyjne;
• decyzje podejmują blisko klasy – tam, gdzie nauczyciel lub koordynator ma realny wpływ na używane narzędzia;
• mają świadomego lidera, który rozumie ryzyko pilotażu i potrafi „osłonić” projekt przed wewnętrznym oporem.

W praktyce dobry partner pilotażowy to często nie ta największa instytucja, ale ta średnia, która potrafi szybko decydować i dać szczery feedback. Mniejsze placówki potrafią testować intensywniej niż duże systemy szkolne, w których każdy krok wymaga kilku podpisów.

Ustalanie zasad współpracy z partnerem

Żeby uniknąć nieporozumień, dobrze jest na początku jasno spisać, co kto wnosi do pilotażu. Nie musi to być formalna umowa – często wystarczy 1–2-stronicowe porozumienie, wysłane mailowo i zaakceptowane przez dyrektora lub koordynatora.

W takim dokumencie można doprecyzować:

• czas trwania pilotażu i liczbę uczestników (np. 2 klasy, 3 miesiące);
• zakres wsparcia zespołu – ile szkoleń, jak szybki czas reakcji na zgłoszenia, kto jest osobą kontaktową po obu stronach;
• warunki finansowe – czy pilotaż jest bezpłatny, częściowo płatny (np. symboliczna opłata), czy powiązany z późniejszym rabatem przy wdrożeniu;
• kwestie danych – kto jest administratorem danych, gdzie są przechowywane, jak długo i na jakich zasadach.

Takie uporządkowanie daje obu stronom poczucie bezpieczeństwa. Dla was to również moment, w którym widać, czy partner traktuje projekt poważnie – jeśli po kilku tygodniach nie jest w stanie zaakceptować prostego porozumienia, trudno liczyć na sprawne wdrożenie.



Skalowanie po pierwszych sukcesach: od pilotażu do produktu na rynek

Jak interpretować wyniki pierwszych pilotaży

Pierwszy pilotaż rzadko daje jednoznaczną odpowiedź „tak” lub „nie”. Zespół musi wspólnie przeanalizować zarówno liczby, jak i jakościowe wnioski. Dobrym podejściem jest podział obserwacji na trzy kategorie:

• „Must fix” – rzeczy, które blokują użyteczność (np. logowanie działa losowo, uczniowie gubią hasła, nauczyciel nie widzi wyników).
• „Nice to have teraz” – funkcje, które znacząco podniosą komfort kluczowych użytkowników pilotażu (np. eksport do Excela dla wychowawcy).
• „Później lub nigdy” – sugestie pojedynczych osób, które nie są spójne z waszym głównym scenariuszem (np. integracja z rozwiązaniami używanymi w jednej, konkretnej szkole).

Wspólne przejście przez listę wniosków pomaga uniknąć sytuacji, w której zespół techniczny reaguje tylko na głośniejsze głosy, a osoba od produktu patrzy wyłącznie na wskaźniki biznesowe. Im bardziej transparentna jest ta selekcja, tym łatwiej rozmawiać z kolejnymi partnerami.

Powielanie udanego wzorca zamiast wymyślania wszystkiego od nowa

Jeśli pilotaż w jednym środowisku się udał, naturalną pokusą jest pójście „wszędzie naraz”. Zwykle skuteczniejsze jest skopiowanie konkretnego wzorca wdrożenia: podobny typ szkoły, zbliżona wielkość, porównywalny poziom cyfryzacji.

Można przygotować prosty „pakiet startowy” dla nowych klientów, oparty na tym, co zadziałało u pierwszego partnera:

• krótka prezentacja dla rady pedagogicznej lub zespołu HR,
• scenariusz pierwszych 2–3 lekcji / spotkań z użyciem narzędzia,
• gotowy plan komunikacji do rodziców/uczestników,
• szablony maili, instrukcji i materiałów wideo.

Dzięki temu każda kolejna instytucja nie wymaga wymyślania komunikacji od zera. Zespół może skupić się na różnicach zamiast za każdym razem przechodzić pełny cykl prób i błędów.

Zarządzanie zespołem na dłuższym dystansie

Rytm pracy w zespole łączącym etaty, studia i start-up

Większość założycieli edtechu przez długi czas łączy projekt z innymi obowiązkami. Chaos zaczyna się wtedy, gdy każdy pracuje „po trochu, kiedy ma chwilę”, a nikt nie wie, co naprawdę posuwa sprawy naprzód.

Sprawdza się prosty, powtarzalny rytm:

• tygodniówka online (30–45 minut) – szybki przegląd: co zostało zrobione, co blokuje, co jest priorytetem na kolejny tydzień; bez wchodzenia w szczegóły techniczne;
• tablica zadań (np. Kanban) widoczna dla wszystkich – kilka kolumn („do zrobienia”, „w trakcie”, „do sprawdzenia”, „zrobione”), bez rozdmuchanych workflowów;
• kwartalny przegląd – co 3 miesiące rozmowa o większym obrazku: czy nadal gramy w tę grę, czy pivotujemy, czy kończymy eksperyment.

W jednym z zespołów budujących narzędzie do planowania lekcji ustalono, że każda osoba ma maksymalnie 2 zadania „w trakcie” jednocześnie. Taki limit, choć prosty, znacząco zmniejszył poczucie rozproszenia i „rozgrzebywania wszystkiego po trochu”.

Budowanie kultury szczerej informacji zwrotnej w małym zespole

W małym start-upie nie ma miejsca, by miesiącami zamiatać konflikty pod dywan. Jednocześnie brak formalnej struktury ułatwia otwartą komunikację, jeśli od początku zadba się o kilka zasad:

• oddzielanie faktów od interpretacji – „zadanie X jest nieukończone od 3 tygodni” zamiast „ty zawsze zwlekasz”;
• wyznaczony czas na feedback – np. 15 minut raz na dwa tygodnie po tygodniówce, zamiast zrywów „przy okazji”;
• jasność co do decyzji – kto ma ostatnie słowo w sprawach produktu, technologii, finansów; nie każda decyzja musi być konsensusem.

Radzenie sobie z wypaleniem i spadkiem motywacji

Przy projekcie, który ciągnie się miesiącami po godzinach, zmęczenie nie jest wyjątkiem, tylko normą. Wypalenie pojawia się zazwyczaj nie dlatego, że jest dużo pracy, ale dlatego, że zespół traci poczucie sensu i sprawczości.

Pomaga kilka prostych mechanizmów:

• małe, domknięte cele – zamiast abstrakcyjnego „zbudujemy platformę”, tydzień poświęcony tylko na „logowanie działa bezbłędnie dla 20 uczniów z pilotażu”;
• widoczność efektów – cykliczne dzielenie się cytatami od nauczycieli, screenami z użycia, krótkimi nagraniami z klasy; zespół widzi, że kod nie ląduje w próżni;
• świadome „nie” – wskazywanie obszarów, których zespół na razie nie robi (np. aplikacja mobilna), zamiast cichego dokładania nowych oczekiwań.

W jednym projekcie edtechowym raz w miesiącu organizowano krótkie „demo dla siebie”: każdy pokazywał coś, z czego jest dumny – nawet jeśli to drobiazg w panelu administracyjnym. Dla wielu osób była to jedyna chwila, gdy widziały całość, a nie tylko swój wycinek.

Dzielenie się rolami bez biurokracji

Mały zespół szybko wpada w pułapkę „wszyscy za wszystko odpowiedzialni”. To pozornie demokratyczne, ale w praktyce oznacza, że nikt nie decyduje i nikt nie trzyma ciągłości tematów.

Zamiast rozbudowanych opisów stanowisk, lepiej rozpisać 5–7 kluczowych obszarów i przypisać do nich właścicieli:

• produkt (kto decyduje, jakie funkcje powstają i jak wyglądają);
• technologia (architektura, wybór narzędzi, standardy jakości kodu);
• klienci i sprzedaż (kontakt ze szkołami, rozmowy ofertowe, pilotaże);
• wsparcie użytkowników (kto odpowiada na maile, zgłoszenia, błędy);
• finanse i formalności (faktury, umowy, dotacje, rejestry);
• marketing i komunikacja (strona www, social media, materiały);
• kultura zespołu (spotkania, retrospekcje, onboardingi nowych osób).

„Właściciel” nie musi wszystkiego robić sam, ale ma mandat do podejmowania decyzji i pilnowania ciągłości. Przy przejściu z fazy hackathonu do dłuższego biegu właśnie ta jasność ról często decyduje, czy projekt się nie rozmyje.

Technologia w edtechu: stabilność ważniejsza niż fajerwerki

Świadomy wybór stosu technologicznego

W edukacji użytkownicy rzadko pytają o framework front-endowy czy bazę danych. Ich obchodzi, czy platforma się nie wiesza na sprawdzianie i czy uczniowie nie gubią postępów. Dlatego główne kryteria wyboru technologii są prozaiczne:

• zespół potrafi to utrzymać – lepiej postawić na narzędzia znane programistom niż na modne, ale egzotyczne rozwiązania;
• łatwo się zatrudnia i szkoli innych – stos używany powszechnie w danym kraju/regionie ułatwia późniejsze powiększanie zespołu;
• dobre wsparcie bezpieczeństwa – aktualizacje, biblioteki do obsługi logowania, szyfrowania, zgodność z wymogami prawnymi.

Pokusą jest też nadmierne kombinowanie z architekturą: mikroserwisy, wielopoziomowe API, rozbudowane kolejki. W większości młodych start-upów edukacyjnych monolityczna, dobrze utestowana aplikacja będzie tańsza w utrzymaniu i wystarczająca przez długi czas.

Bezpieczeństwo i prywatność danych uczniów

Praca z danymi dzieci i młodzieży stawia poprzeczkę wyżej niż w wielu innych branżach. Dyrektorzy szkół pytają o RODO/GDPR nie dlatego, że lubią dokumenty, ale dlatego, że ponoszą realną odpowiedzialność.

Podstawą są trzy obszary:

• minimalizacja danych – zbieranie tylko tego, co jest konieczne do działania narzędzia; często nie trzeba pełnych imion i nazwisk, wystarczą inicjały lub identyfikatory;
• przejrzysta polityka prywatności – napisana prostym językiem, do pokazania zarówno dyrekcji, jak i rodzicom; bez kopiowania losowych wzorów z internetu;
• procedury na wypadek incydentu – scenariusz „co robimy, jeśli coś pójdzie nie tak”: jak szybko informujemy szkołę, jak zabezpieczamy dane, kto jest odpowiedzialny za komunikację.

Dobrą praktyką jest też „przejście ścieżki ucznia i nauczyciela” pod kątem prywatności: czy gdzieś nie pojawiają się dane w logach, screenshotach, materiałach marketingowych. Kilka godzin takiego przeglądu bywa tańsze niż miesiące gaszenia pożarów.

Testowanie z prawdziwymi użytkownikami, nie tylko QA

Nawet najbardziej skrupulatne testy techniczne nie wychwycą wszystkiego, co wydarzy się w klasie. Nauczyciel z 25 uczniami, słabym internetem i lekcją skróconą przez apel szkolny używa narzędzia inaczej niż tester z listą kroków.

Sprawdzają się krótkie, kontrolowane sesje:

• 1–2 klasy, jedna lekcja, zespół obserwuje z tyłu lub przez kamerę;
• proste zadanie dla uczniów (np. zalogowanie się i wykonanie jednego ćwiczenia);
• 5–10 minut rozmowy z nauczycielem na gorąco po lekcji.

W takich warunkach wychodzą na jaw problemy, których nikt nie przewidział: domyślne ustawienia przeglądarek w pracowni, filtry treści blokujące część strony, zamieszanie przy resetowaniu haseł. To lepszy materiał do rozwoju produktu niż kolejne godziny syntetycznych testów.



Ekonomia projektu: między grantem a płacącym klientem

Granty, konkursy, akceleratory – jak nie utknąć w „projektologii”

W edtechu łatwo o pokusę życia od konkursu do konkursu. Granty edukacyjne, programy ministerialne, akceleratory uczelniane – to wszystko może bardzo pomóc, ale ma też ciemną stronę: narrację oderwaną od realnego klienta.

Wybierając konkursy i programy wsparcia, dobrze zadać sobie kilka pytań:

• czy wymagania raportowe nie pochłoną większości czasu zespołu;
• czy kryteria sukcesu programu są spójne z waszym celem (np. liczba uczestników vs. jakość wdrożenia w jednej szkole);
• czy organizator daje dostęp do realnych partnerów (szkoły, samorządy, wydawnictwa), czy tylko do sceny i dyplomu.

Grantom przydaje się zasada: „finansują eksperyment, nie utrzymują firmy”. Jeśli model działania opiera się wyłącznie na kolejnych projektach, trudno zbudować stabilny produkt i zespół.

Budowa prostego modelu przychodów

Wieczne „jeszcze nie wiemy, ile to będzie kosztowało” bywa wygodne dla założycieli, ale dezorientuje szkoły. Nawet w fazie pilotażu opłaca się przetestować choćby uproszczony model przychodów.

Najczęstsze warianty w edtechu to:

• abonament za szkołę – stała opłata za rok, niezależnie od liczby uczniów (do ustalonego limitu);
• opłata od użytkownika – szkoła płaci za aktywne konta uczniów lub nauczycieli; łatwiej ją uzasadnić przy narzędziach indywidualnych;
• model mieszany – podstawowa wersja dla szkoły + płatne rozszerzenia lub szkolenia dla wybranych nauczycieli.

Na początku ważniejsze od „optymalnej ceny” jest sprawdzenie, czy instytucja w ogóle jest gotowa zarezerwować budżet na tego typu rozwiązanie. Symboliczna opłata w pilotażu (choćby za szkolenia nauczycieli) zmienia sposób myślenia obu stron: szkoła przestaje widzieć was jako „kolejny darmowy projekt”, a zespół przyzwyczaja się do rozmowy o pieniądzach.

Współpraca z samorządami i większymi organizacjami

Po pierwszych sukcesach w pojedynczych szkołach naturalnym krokiem jest wyjście na poziom gminy, miasta czy kuratorium. Tu jednak zasady gry bywają inne niż w bezpośredniej sprzedaży do placówek.

Przygotowując się do rozmów z większym partnerem, warto:

• mieć konkretne case study – 1–2 dobrze opisane wdrożenia z wynikami i cytatami nauczycieli, a nie tylko prezentację wizji;
• rozumieć cykl budżetowy – kiedy zapadają decyzje, jakie są procedury przetargowe, kto realnie ma wpływ na wybór rozwiązań;
• upewnić się, że technologia jest gotowa na skalę – jeśli w weekend 5 tysięcy uczniów zaloguje się jednocześnie, serwer nie może się poddać.

Czasem lepszym krokiem niż bezpośrednia umowa z dużą instytucją jest pilotaż na poziomie 2–3 szkół z jednego miasta, ale z oficjalnym patronatem czy listem intencyjnym. Daje to wiarygodność, bez natychmiastowego wejścia w ciężkie procedury.

Relacje z nauczycielami i uczniami: współtworzenie, nie tylko „wdrażanie”

Nauczyciele jako współautorzy produktu

Edtech, który powstaje „w oderwaniu od klasy”, zwykle kończy jako kolejne narzędzie, które ładnie wygląda na konferencjach, ale kurzy się w szkolnych zakładkach. Kluczową zmianą jest potraktowanie nauczycieli jak współtwórców, nie tylko odbiorców.

Może to przyjąć różne formy:

• mała rada nauczycieli-doradców spotykająca się raz na 1–2 miesiące online, komentująca plany rozwoju;
• płatne współautorstwo materiałów – scenariuszy zajęć, testów, kursów tworzonych na bazie platformy;
• otwarty kanał komunikacji (grupa, forum), gdzie można szybko skonfrontować koncepcję nowej funkcji z realiami szkoły.

Nawet kilka osób z różnych typów placówek (wieś/miasto, szkoła podstawowa/ponadpodstawowa) potrafi w porę zatrzymać pomysły, które byłyby trudne do użycia w praktyce.

Uczniowie jako źródło szczerego feedbacku

Choć formalnie klientem często jest szkoła, to uczniowie najszybciej pokażą, czy narzędzie ma sens. Oni nie mają interesu, by kadzić zespołowi – jeśli coś jest nudne, skomplikowane lub wolne, usłyszycie to wprost.

Podczas pilotaży opłaca się wygospodarować slot na krótką rozmowę z grupą uczniów. Dwa pytania dużo mówią o kierunku:

• co w tym narzędziu pomaga ci w nauce, a co przeszkadza;
• czy używał(a)byś tego, gdyby nie było obowiązkowe – i dlaczego.

Odpowiedzi często są bolesne, ale bez nich łatwo zbudować system, który „działa” z perspektywy administracji, a jest ignorowany przez tych, którzy powinni z niego korzystać codziennie.

Projektowanie szkoleń dla nauczycieli

Sukces wdrożenia rzadko zależy od liczby funkcji. Częściej kluczowa jest jakość pierwszych godzin pracy nauczyciela z narzędziem. Szkolenie nie powinno być wykładem o możliwościach platformy, tylko warsztatem w oparciu o prawdziwe scenariusze zajęć.

Sprawdza się prosty format:

• krótkie wprowadzenie problemu (np. jak monitorować pracę uczniów na lekcji i w domu);
• przejście przez 1–2 konkretne lekcje zaprojektowane w narzędziu, najlepiej z rolą nauczyciela i ucznia;
• czas na samodzielną adaptację – nauczyciel przerabia przykładowy scenariusz na swój przedmiot lub klasę.

Po takim spotkaniu nauczyciel wychodzi nie tylko z kontem i hasłem, ale z pierwszą własną lekcją. To ogromnie zwiększa szansę, że wróci do narzędzia w kolejnym tygodniu.

Od hackathonu do firmy: formalności bez paraliżu

Kiedy „zabawić się w firmę”, a kiedy nią zostać

Wielu zespołom po hackathonie towarzyszy presja: „musimy szybko założyć spółkę, inaczej nikt nas nie potraktuje poważnie”. Tymczasem przez pierwsze miesiące często wystarczy działanie w luźniejszej formule, np. na umowach cywilnoprawnych, z jednym podmiotem prowadzącym rozliczenia.

Przejście do formalnej struktury (np. spółki z o.o.) zaczyna mieć sens, gdy:

• pojawiają się pierwsi płacący klienci i konieczność wystawiania faktur regularnie;
• zespół chce jasno uregulować udziały i przyszłe decyzje właścicielskie;
• rozważany jest zewnętrzny inwestor lub większy grant wymagający konkretnej formy prawnej.

Lepszym kryterium niż „ładnie wygląda na LinkedInie” jest odpowiedź na pytanie: czy nowa forma prawna ułatwia nam zawieranie umów i rozwój, czy tylko generuje koszty księgowe i dodatkowe raporty.

Ustalenia udziałowe w zespole założycielskim

Najczęściej zadawane pytania (FAQ)

Jak przejść od pomysłu z hackathonu do realnego start-upu edukacyjnego?

Kluczowe jest potraktowanie hackathonu jako początku, a nie finału. Zespół musi podjąć świadomą decyzję „idziemy dalej”, a dopiero potem inwestować czas w doprecyzowanie problemu, rozmowy z nauczycielami, rodzicami czy uczniami oraz pierwsze pilotaże.

Po wydarzeniu warto szybko ocenić pomysł (np. prostą matrycą kryteriów), ustalić role w zespole, zaplanować budowę MVP na 4–8 tygodni i umówić się na konkretny cel na pierwsze 3 miesiące pracy.

Jak wybrać dobry pomysł edtechowy podczas hackathonu?

Już w trakcie hackathonu trzeba zadać kilka twardych pytań: kto ma realny problem, czy użytkownik ma motywację, by zmienić swoje zachowanie, czy ktoś potencjalnie mógłby za to zapłacić oraz czy pierwszą wersję da się zbudować w 4–8 tygodni po wydarzeniu.

Dobry pomysł edtechowy uwzględnia też specyfikę edukacji: ograniczony czas nauczycieli, cykl roku szkolnego, infrastrukturę IT w szkołach oraz wymogi dotyczące ochrony danych uczniów. Pomysł, który ignoruje te czynniki, zwykle kończy jako „fajne demo”, a nie produkt.

Na co zwrócić uwagę, tworząc MVP produktu edukacyjnego po hackathonie?

MVP powinno być możliwe do zbudowania po godzinach w 4–8 tygodni i rozwiązywać jeden konkretny, bolesny problem użytkownika (np. ograniczenie papierologii, oszczędność czasu, lepsze wyniki uczniów). Zamiast rozbudowanej platformy często lepiej stworzyć prosty dodatek do narzędzi już używanych w szkole lub firmie.

Warto też upewnić się, że rozwiązanie działa na realnym sprzęcie szkół/uczelni, nie wymaga od nauczycieli dodatkowych 30 minut dziennie i jest zgodne z zasadami ochrony danych osobowych (np. RODO).

Jak ocenić, czy pomysł z hackathonu ma potencjał biznesowy w edukacji?

Pomóc może prosta matryca oceny, w której przyznajesz punkty (1–5) za: siłę problemu, dostęp do użytkowników (czy w 2–3 tygodnie porozmawiasz z 10–20 osobami), prostotę MVP, potencjał monetyzacji w ciągu 12–18 miesięcy oraz dopasowanie pomysłu do kompetencji zespołu.

Jeśli któryś z obszarów wypada dramatycznie słabo (np. brak kontaktu z użytkownikami lub nierealne MVP), lepiej zmodyfikować pomysł lub go odpuścić, zamiast ciągnąć projekt z przyzwyczajenia.

Jak zbudować realny zespół po hackathonie i podzielić role?

Po hackathonie trzeba wyjść z trybu „wszyscy robią wszystko”. Typowy start-up edukacyjny potrzebuje przynajmniej ról odpowiedzialnych za: produkt i użytkownika, technologię, biznes i sprzedaż oraz operacje i formalności (np. granty, umowy, podstawowa księgowość).

Dobrym krokiem jest krótka sesja online, w której każdy deklaruje, za który obszar jest gotów odpowiadać przez najbliższe 3 miesiące i ile czasu tygodniowo realnie może poświęcić (np. 5, 10, 20 godzin). To minimalizuje późniejsze konflikty i niedomówienia.

Jak utrzymać motywację zespołu po intensywnym hackathonie?

Trzeba od początku oddzielić emocje i adrenalinę hackathonu od długoterminowej pracy nad produktem. Pomaga szczera rozmowa o dostępności czasowej, horyzoncie współpracy (minimum 3–6 miesięcy) oraz oczekiwaniach finansowych – czy traktujemy projekt jako eksperyment, czy celujemy w pełnoetatowy biznes.

Warto spisać prostą „kartę projektu” na 1–2 strony, z celem na 3 miesiące, deklarowanym wkładem czasowym, zasadami podejmowania decyzji i wstępną wizją podziału udziałów. Taki dokument stabilizuje motywację i ułatwia przetrwanie pierwszych, mniej spektakularnych tygodni.

Czym różni się budowa start-upu edukacyjnego od zwykłej aplikacji B2C?

Start-up edukacyjny działa w silnie ustrukturyzowanym środowisku: kalendarz roku szkolnego, procedury szkół i uczelni, ograniczony czas nauczycieli, wrażliwe dane uczniów. Dodatkowo często użytkownik (uczeń, nauczyciel) nie jest płatnikiem (rodzic, szkoła, firma), co komplikuje model biznesowy.

W praktyce oznacza to, że pomysł musi być dopasowany do istniejących struktur i ograniczeń, a nie próbować je od razu zburzyć. Inaczej niż w wielu „zwykłych” apkach B2C, w edtechu kluczowe jest planowanie wdrożeń w zgodzie z kalendarzem szkoły, prostota narzędzia oraz bardzo poważne podejście do bezpieczeństwa i prywatności danych.

Najważniejsze lekcje

• Hackathon nie jest celem samym w sobie, lecz punktem startowym – kluczowa jest świadoma decyzja zespołu „idziemy dalej” i gotowość do dalszej pracy nad produktem.
• W edtechu pomysł musi wynikać z realnego, dotkliwego problemu konkretnych grup (nauczycieli, uczniów, rodziców, szkół, firm), a nie z samej atrakcyjności technologii czy efektownego pitchu.
• Już na etapie hackathonu trzeba weryfikować cztery kwestie: siłę motywacji użytkownika do zmiany zachowania, istnienie przyszłego płatnika, możliwość zbudowania MVP w 4–8 tygodni oraz realność rozwoju bez wieloletnich badań czy decyzji ministerstwa.
• Produkt edukacyjny musi uwzględniać specyfikę środowiska: kalendarz roku szkolnego, przeciążenie nauczycieli, ograniczenia sprzętowe i dostęp do internetu oraz wysokie wymagania związane z ochroną danych uczniów.
• Często lepszą drogą jest dostosowanie pomysłu do istniejących struktur (np. prosty plug‑in do używanego systemu) niż budowa „rewolucyjnej” platformy, która nie pasuje do realiów szkoły czy uczelni.
• Po hackathonie warto zastosować prostą matrycę oceny (problem, dostęp do użytkowników, prostota MVP, monetyzacja, dopasowanie do zespołu), aby wspólnie podjąć racjonalną decyzję o kontynuowaniu lub porzuceniu projektu.
• Aby przejść od „zespołu na weekend” do realnego start-upu, trzeba uporządkować role i odpowiedzialności, szczególnie w obszarach: produktu i użytkownika, technologii oraz biznesu i sprzedaży.

Przeczytaj również:

• 

  Jak wycenić startup edukacyjny przy rozmowie z inwestorem?

• 

  Jak nauczyciel może stworzyć własny mini-startup edukacyjny?

• 

  Hackathony edukacyjne dla uczniów – projekt z Francji

• 

  Startup edukacyjny? Te konkursy sfinansują Twój pomysł!

• 

  Startup edukacyjny w Twojej klasie – jak go przetestować?

• 

  Startup school – edukacja przedsiębiorcza od podstaw