← wszystkie wpisy
Case study

Wykuwator - platforma SaaS do nauki historii, którą zbudowałem (case study)

Wykuwator - platforma SaaS do nauki historii, którą zbudowałem (case study)

Wykuwator to aplikacja do nauki historii do matury. Pięć minut dziennie, system inteligentnych powtórek, codzienne wyzwania i ranking. Jestem jej współzałożycielem i zbudowałem całą stronę techniczną: landing, aplikację, backend, płatności i panel administracyjny. To nie jest wdrożenie dla klienta. To mój własny produkt, który działa na produkcji, ma płatności i realnych użytkowników, i właśnie dlatego jest najmocniejszym dowodem tego, co potrafię zbudować od zera do końca.

Poniżej opisuję, co konkretnie zbudowałem, jakie decyzje techniczne podjąłem i gdzie taki projekt ma sens. Uczciwie oddzielam swoją rolę od roli wspólnika.

TL;DR

Czym jest: Wykuwator (wykuwator.pl, aplikacja app.wykuwator.pl) to produkcyjna platforma SaaS do nauki historii: silnik powtórek SRS, gry Daily, grywalizacja, ranking, subskrypcja Premium.

Czyj to projekt: mój własny, współtworzony. Spółka pół na pół ze wspólnikiem. Ja odpowiadam za całą technologię, wspólnik za mechanikę dydaktyczną i treść historyczną.

Co zbudowałem: React + Firebase (Firestore, Auth, Cloud Functions), autorski silnik SRS, generator codziennych gier, płatności PayU z weryfikacją po stronie serwera, rozbudowany panel admina, PWA z powiadomieniami push, program poleceń i partnerski.

Stan: na produkcji od września 2026, realni użytkownicy, działające płatności subskrypcyjne.

Po co to tu: jeśli potrzebujesz kompletnej aplikacji webowej, platformy SaaS albo systemu z płatnościami, to nie opis z folderu. To produkt, który zbudowałem i który utrzymuję.

Czym jest Wykuwator

Uczeń ma do opanowania setki dat, postaci i pojęć. Klasyczne wkuwanie z zeszytu jest nudne i nieskuteczne, bo nie pilnuje powtórek w odpowiednim momencie. Wykuwator zamienia to w codzienną grę: pięć zadań dziennie, różne tryby (sortowanie chronologiczne, dopasowywanie par, zgadywanie postaci, wieku, kraju), punkty, passa dni z rzędu i ranking. W tle działa system powtórek, który sam przypomina materiał dokładnie wtedy, kiedy zaczynasz go zapominać.

Baza to ponad 720 wydarzeń i blisko 300 postaci, ułożonych pod wymagania matury. Nauka ma być krótka i wciągająca, a nie kolejnym obowiązkiem.

Moja rola, uczciwie

To spółka pół na pół, więc od razu rozdzielam, kto za co odpowiada.

Wspólnik jest nauczycielem i autorem metody. Odpowiada za mechanikę nauki, dobór materiału, treść historyczną i wizję produktu. To jego pomysł na to, jak uczyć skutecznie.

Ja odpowiadam za całą technologię. Zaprojektowałem architekturę i napisałem cały kod: landing, aplikację, backend, płatności, panel administracyjny i infrastrukturę. Od pustego repozytorium do działającego produktu z płatnościami. Wspólnik nie pisze kodu, ja nie wymyślam metody dydaktycznej. Ten podział działa, bo każdy robi to, na czym się zna.

Piszę o tym wprost, bo w portfolio łatwo zawłaszczyć cudzą część. Tu linia jest czysta: technologia jest moja, dydaktyka jest jego.

Co zbudowałem

Aplikacja i backend

Aplikacja to SPA w React, backend w całości na Firebase: Firestore jako baza, Firebase Auth do logowania, Cloud Functions do logiki serwerowej. Taki stack pozwala jednej osobie prowadzić produkt z realnym ruchem bez utrzymywania własnych serwerów, a jednocześnie daje pełną kontrolę nad danymi i regułami dostępu.

Autorski silnik powtórek (SRS)

Serce produktu to silnik spaced repetition, który sam napisałem na podstawie metody wspólnika. Planuje kolejne powtórki w rosnących odstępach, rozróżnia trzy kategorie trudności fiszek, uwzględnia wskaźnik trudności konkretnej karty i dobiera sesję z materiału, który akurat jest do powtórki. To nie jest gotowa biblioteka, tylko logika napisana pod konkretną metodę nauki.

Codzienne gry Daily

Zestaw pięciu zadań na każdy dzień generuje się automatycznie, z tygodniowym wyprzedzeniem, przez zaplanowaną funkcję w chmurze. Każdy tryb (kolejność, pary, postać, wiek, kraj) ma własny walidator odpowiedzi po stronie serwera. Dzięki temu wynik liczy serwer, a nie przeglądarka.

Płatności PayU

Wdrożyłem subskrypcję Premium przez PayU: stronę płatności, obsługę powiadomień o statusie i weryfikację podpisu po stronie serwera. Tu jedna rzecz potrafi zająć pół dnia, jeśli się jej nie wie: PayU podpisuje powiadomienia skrótem MD5, nie SHA-256, i dopóki weryfikujesz złym algorytmem, każda płatność wygląda na nieprawidłową. Do tego doszła strona prawna: regulamin, polityka prywatności, RODO i zwolnienie z VAT. Płatności działają na produkcji.

Panel administracyjny dla osoby nietechnicznej

Największą wartością dla wspólnika jest to, że może sam zarządzać treścią bez dotykania kodu i bez wpisywania JSON-a. Zbudowałem panel admina z formularzami do wydarzeń, postaci, krajów, synonimów odpowiedzi i portretów, z dashboardem kompletności danych, koszem i cofaniem zmian. Dzięki temu produkt rośnie bez wąskiego gardła w postaci programisty.

Reszta, która składa się na produkt

  • PWA z powiadomieniami push (VAPID), żeby przypomnienie o nauce trafiało na telefon.
  • Logowanie przez Google.
  • Program poleceń i program partnerski z atrybucją odporną na nadużycia, liczoną po stronie serwera.
  • Wiadomości do użytkownika jednym torem naraz: w aplikacji, pushem i mailem.
  • Ranking liczony przez funkcję w chmurze, moderacja nazw graczy, analityka i baner zgody na pliki cookie zgodny z RODO.

Twarde decyzje inżynierskie

Dwie rzeczy decydują o tym, czy taki produkt wytrzyma kontakt z użytkownikami.

Serwer jest źródłem prawdy, nie przeglądarka. Wynik gry, liczniki powtórek i ranking liczy serwer i waliduje odpowiedzi. Gdyby liczyła je przeglądarka, każdy z narzędziami deweloperskimi podmieniłby sobie punkty i zepsuł ranking innym. To ta sama zasada, którą stosuję w konfiguratorach z ceną: klient dostaje wynik, nie mechanizm, który go wylicza.

Reguły dostępu do danych są domknięte. Dane użytkownika może czytać tylko on sam albo administrator, zapisy idą przez funkcje serwerowe, a reguły Firestore są pokryte testami. Bezpieczeństwo bazy w aplikacji z realnymi kontami i płatnościami nie jest opcją.

Efekt, uczciwie

Wykuwator działa na produkcji od września 2026. Ma realnych użytkowników, działające płatności i prowadzoną kampanię docierającą do szkół. Nie będę tu żonglował liczbami sprzedaży, bo produkt wciąż rośnie, a wcześnie na wnioski. To, co mogę pokazać, jest konkretne: żywa aplikacja, którą da się kliknąć, z pełnym obiegiem od rejestracji przez naukę po płatność.

Dla mnie, jako developera, najważniejszy jest inny wynik. Przeszedłem całą drogę od pustego repozytorium do produktu, który przyjmuje pieniądze i obsługuje ludzi. To coś innego niż zrobienie strony na zlecenie i oddanie jej. Tu sam utrzymuję, naprawiam i rozwijam to, co zbudowałem.

Co to znaczy, jeśli szukasz wykonawcy

Wykuwator to dowód kompetencji, nie referencja z Twojej branży. Jest edukacyjny i kierowany do uczniów, więc nie udaję, że to projekt B2B. Ale jeśli potrzebujesz czegoś z tej półki technicznej, to już to zbudowałem i prowadzę:

  • kompletną aplikację webową albo platformę SaaS,
  • logowanie, konta użytkowników i role,
  • płatności, w tym subskrypcje,
  • panel administracyjny, w którym Twój zespół sam zarządza treścią,
  • backend w chmurze, który skaluje się bez własnej serwerowni,
  • logikę liczoną po stronie serwera tam, gdzie nie można ufać przeglądarce.

Jeśli Twój pomysł mieści się w tych ramach, umiem go przeprowadzić od zera do produkcji, bo zrobiłem to dla własnego produktu.

Kiedy taki projekt ma sens, a kiedy nie

Warto, kiedy:

  • masz produkt cyfrowy z kontami, logiką i płatnościami, a nie zwykłą wizytówkę,
  • zależy Ci, żeby osoba nietechniczna sama zarządzała treścią,
  • planujesz rozwój na lata i nie chcesz zależeć od abonamentu gotowej platformy.

Nie warto, kiedy:

  • potrzebujesz prostej strony informacyjnej, bo wtedy cała ta maszyneria to koszt bez zwrotu,
  • chcesz zweryfikować pomysł w tydzień, bez kont i płatności, bo wtedy lepszy jest lekki prototyp,
  • gotowe rozwiązanie z półki pokrywa sto procent Twoich potrzeb, bo wtedy własny kod tylko opóźnia start.

Często zadawane pytania

Czy Wykuwator to był projekt dla klienta?

Nie. To mój własny produkt, który współtworzę jako współzałożyciel. Pokazuję go, bo najlepiej dowodzi, że umiem doprowadzić aplikację z płatnościami od pomysłu do działającej produkcji, i bo mam prawo go pokazać. Projektów klienckich bez zgody nie publikuję.

Czy zbudujesz podobną aplikację albo platformę SaaS dla mnie?

Tak, to jest dokładnie moja działka. Aplikacje webowe, platformy z kontami i płatnościami, panele administracyjne, backend w chmurze. Napisz, co chcesz osiągnąć, a powiem uczciwie, czy i jak to zrobić.

Ile kosztuje taka aplikacja?

Zależy od zakresu. Prosta aplikacja z kontami to inny pułap niż platforma z płatnościami, panelem admina i logiką serwerową. Wycenę podaję na piśmie przed startem, bez „od" bez sufitu. Opisz zakres, a policzę konkret.

Firebase czy własny backend, co wybrać?

Firebase jest świetny, kiedy jedna osoba albo mały zespół ma prowadzić produkt bez utrzymywania serwerów, a logika mieści się w funkcjach w chmurze. Własny backend wygrywa przy nietypowych integracjach, ciężkich obliczeniach albo wymaganiach, których model Firebase nie obsługuje wygodnie. Dobieram narzędzie do projektu, nie odwrotnie.

Jak działają płatności subskrypcyjne w takiej aplikacji?

Przez operatora płatności, u mnie PayU: strona płatności, obsługa powiadomień o statusie i weryfikacja podpisu po stronie serwera, a do tego regulamin, polityka prywatności i RODO. Subskrypcję i dostęp do funkcji Premium pilnuje serwer, nie przeglądarka.

Czy zrobisz platformę kursową albo e-learning?

Tak. Wykuwator jest platformą edukacyjną, więc tę domenę znam od środka: konta uczniów, postępy, treści, płatności, panel autora. Jeśli planujesz sprzedawać kursy albo naukę online pod własną marką, to jest w moim zakresie.

Co z utrzymaniem i skalowaniem?

Backend na Firebase skaluje się bez mojej ingerencji w infrastrukturę, a logika serwerowa i reguły dostępu są pokryte testami. Sam utrzymuję i rozwijam Wykuwatora na produkcji, więc utrzymanie cudzego produktu po wdrożeniu to dla mnie codzienność, nie teoria.

Podobne i następne kroki

Jeśli potrzebujesz aplikacji webowej albo systemu z logiką biznesową, zajrzyj do aplikacji webowej na zamówienie. Jeśli myślisz o sprzedaży kursów albo nauki online, zobacz platformę kursową online. A jeśli chcesz zobaczyć, jak wygląda premium strona z mocnym efektem wizualnym, jest case study STEPTRADE i portal B2B Ustawnik.pl.

Masz pomysł na produkt cyfrowy? Napisz do mnie. Powiedz, co chcesz zbudować, a odpowiem uczciwie, czy i jak to przeprowadzić.

Masz projekt na oku?

Napisz - wycenę odeślę do 48 h. Bez agencji, bez pośredników.

✉ napisz: dominik.gronski@grodev.pl
Dominik Groński
Dominik Groński
Full-stack developer · GroDev · Poznań

Buduję custom systemy webowe: Laravel, WooCommerce, konfiguratory 3D w Three.js. Piszę bez ściemy, od strony biznesu który to potem utrzymuje. Prowadzę GroDev - studio jednoosobowe z Poznania.

Zadzwoń Darmowa wycena