Nie każdy software house ogarnie EdTech. Co naprawdę pokazują projekty Selleo?

Kiedy ktoś z zewnątrz patrzy na EdTech, łatwo dojść do wniosku, że to po prostu kolejna aplikacja z lekcjami, quizami i panelem administratora. Z naszej perspektywy to jeden z tych obszarów, w których bardzo szybko wychodzi na jaw, czy zespół umie tylko dowozić funkcje, czy naprawdę rozumie produkt. To dobrze widać w projektach, które mamy w portfolio. Mamy tam platformę przygotowującą do egzaminu, produkt dla szkół, rozwiązania dla corporate learningu i platformę AI dla zespołów L&D. To nie są różne wersje tego samego LMS-a, tylko różne typy produktów learningowych, które wymagają zupełnie innego myślenia o architekturze, treści i użytkowniku.

Najważniejsze wnioski z artykułu

• EdTech robi się trudny wtedy, gdy trzeba połączyć treść, role użytkowników, integracje, dane i compliance w jednym produkcie.

• Najmocniejsze case’y Selleo pokazują nie jedną specjalizację, tylko kilka modeli budowania produktów learningowych.

• Skumani jest dobrym przykładem, bo łączy AI, content, CMS, gamifikację i logikę sprzedażową w jednej platformie.

• W tych realizacjach wraca ten sam wzorzec: autonomia po wdrożeniu, rozwój modułowy i brak zamknięcia klienta w jednym wykonawcy.

• Ten typ komunikacji najlepiej trafia do Product Ownera lub CTO, który szuka partnera do sensownego rozwoju istniejącej platformy albo budowy nowej od zera.

Dlaczego projekty EdTech są trudniejsze niż zwykły software development?

Kiedy pracujemy nad produktem edukacyjnym, bardzo szybko okazuje się, że to nie jest tylko „aplikacja do nauki”. Dochodzi logika uczenia, wiele ról w systemie, raportowanie postępów, sposób zarządzania treścią i wymagania formalne. W EdTechu software jest tylko jedną warstwą większego systemu, a nie celem samym w sobie.

Druga rzecz to użytkownicy. W zwykłym SaaS-ie masz często jedną główną personę i kilka pobocznych scenariuszy. Tutaj uczeń, nauczyciel, administrator, rodzic albo zespół L&D działają inaczej, widzą inne rzeczy i oczekują czegoś innego od tego samego produktu. Jeśli platforma nie jest ułożona pod te role, zaczyna się chaos, nawet gdy sam kod jest dobrze napisany.

Trzecia warstwa to treść. Wiele zespołów skupia się na tym, jak coś wyświetlić, ale w produktach learningowych równie ważne jest to, kto tę treść tworzy, aktualizuje, układa w ścieżki i mierzy jej skuteczność. Dobry produkt edukacyjny daje klientowi kontrolę nad contentem, zamiast uzależniać go od deweloperów przy każdej zmianie.

No i zostaje jeszcze temat integracji, prywatności i dalszego rozwoju. W praktyce klient nie pyta tylko o to, czy platforma działa dziś. Pyta też, czy da się ją rozbudować za pół roku, połączyć z innymi systemami i utrzymać bez przepisywania wszystkiego od nowa. To właśnie w takich momentach widać różnicę między zwykłym wdrożeniem a dojrzałym developmentem EdTech.

Jakie case’y z portfolio Selleo naprawdę dowodzą kompetencji w EdTech?

Patrząc na nasze portfolio, najciekawsze jest nie to, ile projektów zrobiliśmy, tylko jak różne problemy one rozwiązują. Mamy exam-prep z AI, platformę dla szkół, rozwiązanie dla microlearningu w firmach i narzędzie AI dla zespołów szkoleniowych. To pokazuje, że nie poruszamy się w jednym szablonie produktu, tylko rozumiemy kilka różnych modeli uczenia i pracy z wiedzą.

Bardzo dobrym przykładem jest EdTech Case Study Selleo Skumani. To nie był projekt, w którym ktoś po prostu dodał chatbota do kursów. Było tam MVP dowiezione w 4 miesiące, 3 nauczycieli AI, 300+ lekcji i quizów oraz 900+ formatów edukacyjnych. Najważniejsze było jednak to, że AI, CMS, struktura treści i mechaniki budujące regularność działały tam jako jeden spójny produkt.

Z kolei Defined Careers pokazuje zupełnie inny typ wyzwania. Tam nie chodziło o szybkie przygotowanie kursu pod jeden segment użytkowników, tylko o większy system dla szkół z różnymi rolami, ścieżkami rozwoju, portfolio ucznia i raportowaniem. Przy skali 600+ projektów, 400+ karier i 79 ścieżek nie wystarczy „ładny interfejs”, bo produkt musi być logiczny dla całego ekosystemu szkoły.

Qstream i platforma AI dla L&D poszerzają ten obraz jeszcze bardziej. Tu wchodzimy już w corporate learning, czyli obszar, gdzie liczy się nie tylko doświadczenie użytkownika, ale też retencja wiedzy, analytics, workflow menedżerski i kontrola nad procesem tworzenia treści. Jeśli ktoś pyta, czy EdTech kończy się na szkolnych platformach, odpowiedź brzmi: nie, bo learning product w firmie bywa równie złożony, a czasem nawet bardziej.

Co powtarza się w tych realizacjach i pokazuje prawdziwą przewagę produktową Selleo?

Gdy patrzę na te projekty z perspektywy osoby, która tłumaczy je klientowi, widzę jeden wspólny mianownik. Nie chodzi o konkretny stack ani o jedną „magiczną” funkcję. Przewaga pojawia się tam, gdzie da się połączyć technologię z logiką produktu i realnym sposobem pracy użytkownika.

Pierwszy powtarzalny wzorzec to autonomia po wdrożeniu. Klient nie chce wracać do software house’u po każdą zmianę w kursie, quizie czy materiale dla AI. Chce mieć sensowny CMS, uporządkowany authoring i możliwość rozwijania treści własnymi siłami. To brzmi banalnie, ale właśnie tutaj wiele produktów edukacyjnych zaczyna się blokować po starcie.

Drugi wzorzec to rozwój modułowy. W praktyce mało kto zaczyna z idealnym produktem i pełną roadmapą na dwa lata. Dużo częściej mamy istniejący kod, presję biznesową, bugi po releasie i potrzebę szybkiego uporządkowania całości bez zatrzymywania rozwoju. Dlatego tak ważne są product recovery, etapowe porządkowanie architektury i decyzje, które nie zamykają klienta na przyszłość.

Trzeci wzorzec to partnerstwo produktowe. Klient nie szuka tylko zespołu, który wykona backlog. Szuka ludzi, którzy pomogą odróżnić to, co naprawdę ważne dla produktu, od tego, co wygląda atrakcyjnie tylko na demo. Z naszej perspektywy najlepsze projekty EdTech powstają wtedy, gdy discovery, architektura i delivery są częścią jednej rozmowy, a nie trzema osobnymi światami.

Jakie wnioski z tych case’ów są najważniejsze dla EdTech / HRTech Product Ownera?

Jeśli miałbym to powiedzieć najprościej, ten materiał najmocniej trafia do osoby, która już wie, że temat jest poważny i nie szuka ogólnego wpisu o trendach w edukacji. Szuka potwierdzenia, że partner rozumie domenę, potrafi wejść w istniejący produkt i nie zgubi się przy integracjach, content workflow czy AI. To jest dokładnie ten moment, w którym portfolio przestaje być „ładną wizytówką”, a zaczyna działać jak dowód kompetencji.

Druga rzecz jest jeszcze bardziej praktyczna. Nie warto oceniać partnera wyłącznie po liczbie case’ów albo po tym, jak efektownie wygląda prezentacja. Lepiej patrzeć na to, czy potrafi jasno opowiedzieć o decyzjach: co było trudne, co dało się uprościć, jak rozwiązano zarządzanie treścią, jak zabezpieczono rozwój produktu. Dobry partner w EdTech daje poczucie porządku, a nie tylko obietnicę szybkiego delivery.

No dobra — o co w tym chodzi w codziennej praktyce? Jeśli testujesz nowy produkt z AI i własnym contentem, liczy się szybkie, modułowe MVP. Jeśli budujesz system dla szkół albo dużej organizacji, ważniejsze stają się role, raportowanie, integracje i architektura. Jeśli w produkcie pojawia się AI, najważniejsze przestaje być samo generowanie, a zaczyna się kontrola nad jakością, źródłami wiedzy i sensem użycia.

Na końcu zostaje jeszcze kwestia zaufania operacyjnego. Za tym portfolio stoi software house z Bielska-Białej, który działa od 2005 roku, ma zespół 100+ osób i ocenę 4.7/5 na Clutch. To nie zastępuje dobrego dopasowania do projektu, ale daje ważny sygnał, że mówimy o partnerze, który umie dowozić i rozwijać produkty w dłuższym horyzoncie.

FAQ

Po czym poznać, że software house naprawdę rozumie EdTech?

Po tym, jak mówi o produkcie. Jeśli rozmowa dotyczy tylko ekranów i funkcji, to za mało. Dobre rozumienie EdTech zaczyna się tam, gdzie pojawiają się role użytkowników, treść, raportowanie, integracje i sposób dalszego rozwoju platformy.

Kiedy gotowy LMS nie wystarczy?

Wtedy, gdy produkt ma własną logikę, kilka grup użytkowników, niestandardowe procesy albo warstwę AI. Gotowe narzędzie da się wdrożyć szybko, ale ma ograniczenia. Custom platform ma sens wtedy, gdy to model działania produktu jest przewagą, a nie sam katalog funkcji.

Jak ocenić, czy AI w learning product jest produktem, a nie tylko demem?

Trzeba sprawdzić, z czego AI korzysta, kto kontroluje odpowiedzi i jak to wpisuje się w realny workflow użytkownika. Sam chatbot nie rozwiązuje problemu. Dojrzałe użycie AI zaczyna się wtedy, gdy technologia jest osadzona w źródłach wiedzy, rolach i konkretnym celu edukacyjnym.

Jakie integracje są krytyczne w projektach learningowych?

Najważniejsze są te, które wpływają na codzienną pracę i dane. W praktyce mówimy o logowaniu, raportowaniu, wymianie treści i połączeniach z innymi systemami klienta. Im większa organizacja albo bardziej złożony ekosystem, tym szybciej integracje przestają być dodatkiem i stają się częścią rdzenia produktu.

Co sprawdzić, gdy partner przejmuje istniejący produkt?

Najpierw stan kodu, jakość architektury i miejsca, w których produkt już teraz hamuje rozwój. Potem sposób przekazania wiedzy, plan stabilizacji i kolejność działań. Przejęcie produktu ma sens wtedy, gdy porządkuje sytuację i daje klientowi większą kontrolę, a nie tylko zmienia wykonawcę.

Jak odróżnić grywalizację wspierającą naukę od dekoracji?

Patrz na zachowanie użytkownika, nie na same elementy wizualne. Punkty, streaki i odznaki mają sens tylko wtedy, gdy wzmacniają regularność, zaangażowanie i powrót do materiału. Dobra gamifikacja pomaga uczyć się konsekwentnie, a nie tylko sprawia, że interfejs wygląda bardziej „fun”.

Artykuł sponsorowany