Z jednego API z pytaniami quizowymi zbudowałem dwa zupełnie różne produkty. Pierwszy to QuizBase - wielojęzyczne API trivia dla deweloperów. Drugi to RoundKit - gotowy wieczór quizowy dla ludzi, którzy organizują quizy i nie chcą co tydzień pisać pytań. Ten sam zbiór pod spodem, dwie kompletnie inne grupy odbiorców, dwa osobne modele biznesowe. To nie przypadek, tylko świadoma decyzja produktowa, która mówi coś istotnego o tym, gdzie dziś naprawdę leży przewaga.
O tym, jak powstało samo API, pisałem w tekście o tym, jak zbudowałem API, nie pisząc kodu. Tutaj historia idzie dalej: co się dzieje, kiedy masz już działające API i zadajesz pytanie “a co jeszcze może z tego wyrosnąć?”.
Jedno źródło treści, dwóch różnych odbiorców
QuizBase i RoundKit stoją na tym samym zbiorze - ponad milion pytań z dwunastu otwartych źródeł, kalibrowanych przez model, w polskim i angielskim. Ale rozmawiają z zupełnie innymi ludźmi.
QuizBase mówi do dewelopera. Dostaje REST API, TypeScript SDK i serwer MCP - czyli surowiec, który sam wbuduje w swoją aplikację, grę czy platformę edukacyjną. Jego potrzeba brzmi: “daj mi pytania w formacie, który podłączę kodem”. Pełen obraz tej warstwy opisywałem przy okazji serwera MCP po polsku.
RoundKit mówi do kogoś, kto kodu nigdy nie zobaczy: właściciela pubu, prowadzącego quiz, nauczyciela, organizatora firmowej integracji. Ten człowiek nie chce obiektu JSON. Chce wydrukować arkusz, włączyć prezentację i poprowadzić wieczór. Jego potrzeba brzmi: “daj mi gotowy materiał, którym poprowadzę quiz dziś wieczorem”.
To są dwaj różni aktorzy z różnymi bólami. Mylenie ich jest klasycznym błędem produktowym - próbą sprzedania jednego produktu wszystkim. Rozdzielenie ich na dwa produkty pozwala każdemu mówić własnym językiem.
Dlaczego ten sam dataset daje dwa produkty
Bo API to półprodukt, a nie produkt. Deweloper potrafi i chce dokończyć resztę sam - dla niego “surowe pytania w JSON” to zaleta, bo daje kontrolę. Organizator quizu utknie na pierwszym kroku. Dla niego ten sam surowiec jest bezużyteczny, dopóki ktoś nie doprowadzi go do końca.
RoundKit robi dokładnie to dokończenie: bierze pytania z API i układa je w gotowy wynik - rundy, arkusze odpowiedzi, prezentację na ekran spójną wizualnie z drukiem. Wartością nie są tu pytania, bo te są na wolnych licencjach i każdy może je pobrać. Wartością jest czas, wygoda i format - to, że nie musisz nic pisać ani składać.
To rozróżnienie między półproduktem a gotowym wynikiem jest sednem. Ta sama podaż treści obsługuje dwa zupełnie różne poziomy “gotowości”, a każdy poziom to inny produkt dla innego klienta.
Co jest prawdziwym moatem, a co nie
Najczęstszy błąd przy takim produkcie to przekonanie, że przewagą jest treść. Nie jest. Skoro pytania pochodzą z otwartych zbiorów na licencjach Creative Commons i MIT - a o tym, jak legalnie zbudować taki dataset, pisałem w tekście o licencjach Creative Commons - to każdy konkurent ma do nich dokładnie taki sam dostęp. Treść nie obroni produktu.
Prawdziwym moatem RoundKitu jest anti-duplikat: mechanizm, który pamięta, jakie pytania już dostałeś, i pilnuje, żeby kolejny tydzień ich nie powtórzył. Dla cotygodniowego prowadzącego to jest realny ból - i jedyna funkcja, której nie da się skopiować, bo jej wartość zależy od historii konkretnego użytkownika i rośnie z każdym tygodniem korzystania.
Tu zresztą oba produkty się spotykają. RoundKit prosi QuizBase o pytania z wykluczeniem tego, co użytkownik już widział - a to znaczy, że anti-repeat musiałem najpierw dołożyć do samego API. Drugi produkt wymusił ulepszenie pierwszego. To jest dogfooding w czystej postaci: kiedy sam jesteś najtrudniejszym klientem swojego API, błędy w jego projekcie wychodzą natychmiast.
Drugi produkt jest dużo tańszy niż pierwszy
Najciekawsze ekonomicznie jest to, że RoundKit kosztował znacznie mniej wysiłku niż QuizBase, mimo że jest produktem bardziej złożonym od strony użytkownika. Powód jest prosty: połowa fundamentów już istniała.
RoundKit konsumuje QuizBase przez ten sam gotowy TypeScript SDK, którego używają zewnętrzni deweloperzy. Decyzje licencyjne, kalibracja trudności, model danych - to wszystko było już rozstrzygnięte przy pierwszym produkcie. Do tego dochodzi dźwignia, którą opisywałem w anatomii produktu AI: kod pisze narzędzie agentowe, a moją rolą jest osąd produktowy, nie implementacja.
To zmienia kalkulację przy każdym kolejnym pomyśle. Kiedy masz dobrze zaprojektowane źródło i taniego “wykonawcę”, każdy następny produkt zbudowany na tym fundamencie jest tańszy od poprzedniego. API przestaje być pojedynczym produktem, a staje się platformą, z której można wyprowadzać kolejne.
Czego nauczyła mnie ta druga warstwa
Po pierwsze, że warto myśleć o API nie jako o produkcie końcowym, lecz jako o fundamencie. Pytanie “kto jeszcze mógłby tego użyć i w jakiej formie” jest pytaniem strategicznym, nie technicznym - i to produktowiec powinien je zadawać najgłośniej.
Po drugie, że bycie własnym klientem jest bezcenne. RoundKit jako konsument QuizBase pokazał mi w praktyce, czego brakuje w API, szybciej niż jakikolwiek zewnętrzny feedback. Drugi produkt to nie tylko nowe źródło przychodu - to także najostrzejszy test jakości pierwszego.
Po trzecie, że przewaga w tym układzie nigdy nie leży w surowcu, tylko w decyzjach: kogo obsługujesz, do jakiego poziomu gotowości doprowadzasz materiał i którą jedną rzecz robisz tak, że nie da się jej skopiować.
Jeśli zastanawiasz się, co Twoja organizacja realnie mogłaby zbudować na własnych danych albo istniejącym API - i gdzie leży w tym przewaga, a gdzie ryzyko - to dokładnie temat, który rozkładam na czynniki pierwsze podczas konsultacji i szkoleń z AI dla firm. Quizów używam zresztą również w samych szkoleniach, o czym piszę w tekście o tym, kiedy quiz w szkoleniu działa, a kiedy przeszkadza.