Developer Mode vs Store

1. Wprowadzenie

W poprzednich wykładach omówiliśmy już, czym jest ChatGPT App, z jakich warstw się składa i czym różni się od starych wtyczek oraz zwykłych botów na OpenAI API. Teraz przejdziemy do drugiego ważnego tematu — cyklu życia takiej aplikacji.

Jeśli od co najmniej kilku lat tworzycie usługi webowe, słowo „lifecycle” was nie przeraża. Każdy produkt ma swój prosty szlak: „napisaliśmy lokalnie → wdrożyliśmy na staging → wdrożyliśmy na production → czasem wszystko zepsuliśmy → naprawiliśmy”. W ekosystemie ChatGPT z App jest podobnie, ale są niuanse: pojawia się Dev Mode wewnątrz samego ChatGPT oraz osobny byt — Store.

Ważne jest wyraźnie oddzielić dwa wymiary:

1. Gdzie fizycznie żyje wasz kod: lokalny serwer Next.js, Vercel, jakiś klaster Kubernetes itd. To wasz świat — tam jesteście panem i władcą.
2. Jak ChatGPT widzi wasz App: jako zestaw metadanych, URL i uprawnień, które można albo podłączyć w Developer Mode, albo opakować jako gotowy produkt w Store. To już świat OpenAI, z własnymi zasadami, review i użytkownikami.

Ten wykład dotyczy właśnie drugiego wymiaru. Będziemy opierać się na waszym zwyczajowym modelu środowisk (dev / staging / prod), ale spojrzymy na niego oczami ChatGPT. Nasz cel — abyście w każdej chwili potrafili odpowiedzieć sobie na kilka pytań. Jaki dokładnie kod uruchamia teraz mój App? Kto go widzi? Jak bezpiecznie eksperymentować? I co właściwie znaczy „zaktualizować App” w Store?

2. Developer Mode: prywatna piaskownica wewnątrz ChatGPT

Zacznijmy od tego, co dla dewelopera najprzyjemniejsze: od piaskownicy, w której można wszystko popsuć i prawie nikogo tym nie skrzywdzić.

Developer Mode to specjalny tryb w ChatGPT, w którym możecie podłączać swoje ChatGPT Apps bezpośrednio po URL, bez przechodzenia review, bez publikacji App w Store i bez pokazywania App całemu światu. W duchu przypomina to localhost:3000 w przeglądarce, tylko w świecie ChatGPT.

Jak to wygląda koncepcyjnie

Najprościej wyobrazić to sobie tak:

flowchart TD
    User("ChatGPT UI (Dev Mode)")
    AppConfig["Konfiguracja dev App (URL + metadane)"]
    AppServer["Twój serwer App (Next.js + Apps SDK)"]

    User -->|żądanie w czacie| ChatGPTCore[GPT]
    ChatGPTCore -->|potrzebny App| AppConfig
    AppConfig --> AppServer
    AppServer -->|UI/narzędzia| ChatGPTCore
    ChatGPTCore --> User

Wy, jako deweloper, w ustawieniach Developer Mode mówicie ChatGPT: „Oto mój App, oto jego URL, oto jak się nazywa i co potrafi”. ChatGPT zaczyna traktować ten URL jako źródło waszej aplikacji. Dopóki nie wyślecie App do Store, zobaczycie go tylko wy (i, ewentualnie, inni członkowie waszego zespołu, jeśli dodacie ich jako deweloperów).

Techniczne szczegóły podłączenia (tunel HTTPS, Vercel i inne przyjemności) omówimy później. Tu najważniejsze jest zrozumieć ideę: Dev Mode to taki „dynamiczny alias” do waszego serwera dev, który ChatGPT potrafi wywoływać.

Jak włączyć Developer Mode

Aby mieć możliwość „podpięcia” swojego lokalnego serwera do interfejsu ChatGPT, musisz aktywować odpowiedni przełącznik w ustawieniach.

• Przejdź pod link https://chatgpt.com/#settings/Connectors/Advanced lub wejdź w Settings -> Connected apps -> Advanced.
• Developer Mode - ON

Gdy tylko to zrobisz, pojawi się przycisk Create App.

Czym Dev Mode różni się od production

Różnica przypomina rozjazd między środowiskiem dev a production w zwykłym webie, ale są pewne specyficzne elementy.

Po pierwsze, widoczność. Wasz App w Dev Mode z reguły nie jest dostępny zwykłym użytkownikom ChatGPT. Widać go tylko dla was i, ewentualnie, dla członków waszej organizacji z odpowiednimi uprawnieniami. Można więc eksperymentować bez obaw, że przypadkowa osoba trafi na pół‑zepsuty UX.

Po drugie, stabilność i eksperymenty. W Dev Mode możecie zmieniać kod choćby co dwie minuty, podnosić lokalny serwer, zabijać go, restartować tunel. ChatGPT będzie starał się trafiać pod wskazany URL, ale nie obrazi się, jeśli czasem zwracacie 500 albo w ogóle nie odpowiadacie — od tego jest dev.

Po trzecie, uprawnienia i polityki. W Dev Mode łatwiej próbować różne konfiguracje. Warto jednak pamiętać, że polityki treści i podstawowego bezpieczeństwa nie znikają nawet w trybie dev: ChatGPT nie pozwoli wam nagle zamienić się w „hakerski App do wszystkiego”. Ramy review Store nie działają tu jeszcze w pełni: nie musicie mieć idealnego listingu, pięknego logotypu itd.

I wreszcie, w Dev Mode zwykle łatwiej diagnozować problemy. Możecie szybko zmieniać logikę, sprawdzać, jakie żądania idą od ChatGPT do waszego serwera, i korygować zachowanie, nie myśląc o „migracji użytkowników”.

Przyjrzeliśmy się już Dev Mode jako prywatnej piaskownicy dla aplikacji i lekko zajrzeliśmy w stronę Store. Teraz ułóżmy to wszystko w zrozumiały „automat stanów” cyklu życia App.

3. Stany ChatGPT App: od szkicu do zdjęcia z publikacji

Ułóżmy to teraz w zrozumiałą „maszynę stanów” dla waszego App. Umownie omówimy cztery główne stany: Draft / Dev-only, Under review, Published i Paused/Removed.

Maszyna stanów cyklu życia

Spróbujmy narysować to jako diagram:

stateDiagram-v2
    [*] --> Draft

    Draft: Dev Mode / szkic
    Review: Under review (Store)
    Published: W Store, dostępny dla użytkowników
    Paused: Paused / Removed

    Draft --> Review: Wyślij na review
    Review --> Draft: Odrzucono / zwrot do poprawek
    Review --> Published: Zatwierdzono
    Published --> Paused: Wstrzymaj / zdejmij
    Paused --> Draft: Wznowienie pracy w trybie dev
    Draft --> Published: Wewnętrzny rollout bez Store (dla organizacji)

W stanie Draft wasz App istnieje tylko jako zasób dev. Możecie podłączyć go w Developer Mode, próbować różne funkcje, ale nie eksponować go w Store.

Gdy uznacie, że App pora pokazać ludziom, wysyłacie go „na review” — to stan Under review. W nim OpenAI (albo wewnętrzny system review w waszej organizacji) sprawdza zgodność z politykami, stabilność, podstawowe bezpieczeństwo i adekwatność UX.

Jeśli wszystko jest w porządku, App trafia do Published: pojawia się w Store albo staje się dostępny dla użytkowników waszej firmy (jeśli to scenariusz korporacyjny). Od tego momentu przychodzą prawdziwi użytkownicy i wszystko, co robicie z kodem i konfiguracją, trzeba planować ostrożniej.

Jeśli tymczasowo nie chcecie, by App był dostępny, można przenieść go do stanu Paused/Removed. W stanie Paused jest ukryty przed nowymi użytkownikami, ale może nadal działać dla już rozpoczętych sesji albo zostać całkowicie wyłączony — szczegóły zależą od implementacji platformy i ustawień.

4. Store: kiedy wasz App staje się produktem

Developer Mode — to wasz prywatny garaż. Store — to już oficjalny salon dealerski. Tu w grę wchodzą użytkownicy, oceny, zasady listingu i review.

Co się zmienia, gdy idziecie do Store

Po pierwsze i najważniejsze: wasz App staje się „produktem”. Pojawia się listing: nazwa, opis, ikona, kategorie, czasem startowe podpowiedzi do dialogu. Na podstawie tych metadanych ChatGPT Store będzie wyszukiwać i rekomendować waszą aplikację użytkownikom, a sam model — rozumieć, w jakich scenariuszach App ma zastosowanie.

Druga ważna rzecz — review i polityki. Zanim App pojawi się w Store, zostanie sprawdzony pod kątem wymagań bezpieczeństwa, treści i UX. To znaczy, że:

• nie wolno po cichu zbierać nadmiarowych danych osobowych;
• nie wolno obiecywać rzeczy, których App nie robi;
• nie wolno wychodzić poza dozwolone kategorie treści.

Jeszcze szczegółowo porozmawiamy o politykach i piaskownicy w kolejnych wykładach, ale już teraz warto traktować Store jako miejsce, do którego przynosicie tylko względnie „wychowane” wersje swojego App.

Trzecia rzecz — odpowiedzialność za stabilność. Gdy bawicie się w Dev Mode, wasze awarie — wasz problem. W Store od waszego App oczekuje się sensownej dostępności, rozsądnej latencji i braku „czerwonych ekranów śmierci” w widżecie. W późniejszych modułach będziemy mówić o SLO, metrykach i review Store właśnie w tym kontekście.

Wersje: dev vs production

Typowe pytanie: „Jeśli zaktualizuję kod, co zobaczy użytkownik?”. W świecie ChatGPT Apps warto myśleć o dwóch „gałęziach” jednocześnie:

• gałąź dev, podłączona do Developer Mode i mogąca wskazywać na serwer dev, siedzący obok waszego IDE;
• gałąź production, skojarzona z opublikowaną konfiguracją w Store i wskazująca na stabilny URL.

Z perspektywy architektury można to wyrazić nawet niewielkim typem w TypeScript w waszym projekcie:

type AppStage = 'dev' | 'production';

interface ChatGPTAppConfig {
  id: string;
  stage: AppStage;
  endpointUrl: string;
}

const giftGeniusDev: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'dev',
  endpointUrl: 'https://dev.giftgenius.example.com',
};

const giftGeniusProd: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'production',
  endpointUrl: 'https://app.giftgenius.example.com',
};

W prawdziwym życiu konfigurację przechowuje nie wasz kod, lecz platforma ChatGPT, ale podobne struktury pomagają pamiętać, że to dwa różne „obrazy” tego samego App.

Release ChatGPT App bardziej przypomina wydanie aplikacji w Apple App Store niż aktualizację strony. Wasze widgety i mcp-tools są za każdym razem cache’owane przy wydaniu aplikacji. A review może trwać 2 tygodnie. Więc żadnego „wypuścimy na production i tam dotestujemy”. Do review należy oddawać już w pełni przetestowaną i stabilną aplikację.

5. Kontekst organizacyjny: konto prywatne vs firma

Podzieliliśmy już App na gałąź dev i production i zobaczyliśmy, jak odbija się to w Store. Kolejny ważny wymiar cyklu życia — to „gdzie” on żyje organizacyjnie.

W najprostszym przypadku tworzycie App jako osoba prywatna, na swoim ChatGPT Plus. Wtedy Dev Mode jest tylko wasz, Store — też pod waszym kontem. Wszystko jest względnie proste: zrobiliście dla siebie, opublikowaliście, ucieszyliście świat.

Bardzo często jednak ChatGPT Apps żyją w kontekście korporacyjnym. Pojawia się wtedy kilka dodatkowych ról. Są administratorzy organizacji, którzy decydują, które Apps są dostępne pracownikom, które trzeba zablokować, które można udostępnić tylko grupie pilotażowej. Wasz App może być opublikowany nie dla całego świata, ale tylko dla konkretnej firmy, a nawet konkretnych działów w jej ramach.

W takim scenariuszu cykl życia może wyglądać tak: najpierw App istnieje tylko jako projekt dev wewnątrz zespołu, później pojawia się „wewnętrzny production” — dostępny, na przykład, tylko dla działu sprzedaży w pilocie. Dopiero potem, jeśli wszystko idzie dobrze, decydujecie się wysłać App do globalnego Store, aby stał się produktem zewnętrznym.

Dla architektury to ważne, bo trzeba projektować App tak, by działał sensownie i jako narzędzie wewnętrzne, i jako produkt publiczny. Czasem oznacza to obecność flag funkcji, trybów „tylko dla swoich” oraz osobnych ustawień uwierzytelniania.

6. Praktyczny scenariusz: cykl życia GiftGenius

Żeby to wszystko nie zostało abstrakcją, spójrzmy na przykładowy App GiftGenius — pomocnika w doborze prezentów, który będzie nam towarzyszył w kursie.

Etap 1. Pomysł i wstępny prototyp w Dev Mode

Decydujecie się zrobić GiftGenius: App, który pyta użytkownika, dla kogo potrzebny jest prezent, na jaki budżet liczy i jakie zainteresowania ma obdarowywany, a następnie proponuje opcje, korzystając z waszego katalogu produktów.

Na pierwszym kroku:

1. Stawiacie prosty projekt Next.js z minimalnym widżetem.
2. Włączacie Developer Mode w ChatGPT i dodajecie tam URL swojego serwera dev.
3. Prowadzicie kilka testowych dialogów: prosicie GPT „Pomóż wybrać prezent dla kolegi‑gracza do 50 $” i patrzycie, jak wywołuje wasz App, renderuje widżet i jak wygląda UX.

Na tym etapie nie myślicie o Store, review, ładnych ikonach. Wasze zadanie — udowodnić sobie i zespołowi, że pomysł działa i że platforma ChatGPT pozwala zrealizować potrzebny scenariusz.

Etap 2. Wzmocnienie prototypu i wewnętrzna „alfa”

Kiedy upewnicie się, że podstawowy scenariusz działa, zaczyna się etap „utwardzania”. Robicie:

• porządkujecie logikę do w miarę czytelnej struktury;
• zastanawiacie się, jakie uprawnienia i dane są rzeczywiście potrzebne App;
• sprawdzacie, jak App zachowuje się przy błędach (np. gdy katalog produktów nie odpowiada).

Wciąż w Dev Mode, ale już nie solo: dodajecie kolegów jako deweloperów lub testerów, aby i oni mogli podłączyć App do swojego ChatGPT. Cykl życia w tym etapie kręci się wokół stanu Draft: szybko aktualizujecie kod, próbujecie różne wzorce UX, zbieracie feedback wewnątrz zespołu.

Etap 3. Przygotowanie do Store i review

W tym kroku mówicie: „Tak, GiftGenius jest już na tyle przyzwoity, żeby pokazać go użytkownikom zewnętrznym”. Teraz fokus przesuwa się z kodu na opakowanie produktu:

• piszecie uczciwy i zrozumiały opis App;
• konfigurujecie uprawnienia: wyjaśniacie, do jakich danych App sięga i po co;
• upewniacie się, że UX nie wprowadza w błąd i że App nie obiecuje niemożliwego.

To moment przejścia z Draft do Under review. Wysyłacie App na review i przez jakiś czas żyje on w tym stanie pośrednim. Możliwe, że dostaniecie uwagi: trzeba doprecyzować politykę prywatności, poprawić sformułowania, zawęzić uprawnienia. Wracacie do Draft, poprawiacie, wysyłacie ponownie.

Etap 4. Publikacja i „prawdziwe życie”

Po zatwierdzeniu wasz GiftGenius trafia do stanu Published. Teraz mogą go znajdować użytkownicy w Store, ChatGPT może go proponować przy trafnych zapytaniach, a wy zaczynacie zbierać realny feedback, patrzeć na użycie i myśleć o skalowaniu.

Teraz każda zmiana kodu to już nie tylko „oj, szybko dopiszę funkcję”. To mini‑release. Musicie myśleć o kompatybilności wstecznej, planować migracje, w miarę możliwości najpierw zmieniać wersję dev, sprawdzać ją, a dopiero potem aktualizować konfigurację production.

W razie potrzeby możecie tymczasowo przenieść App do Paused, jeśli np. znaleźliście krytyczną podatność albo wasz backend nie radzi sobie z obciążeniem. Idealny obrazek to jednak stopniowy rozwój gałęzi Published, bez zapominania o środowisku dev do eksperymentów.

7. Jak programista powinien myśleć o środowiskach: dev, staging, production + Dev Mode

Na przykładzie GiftGenius przeszliśmy drogę od pomysłu w Dev Mode do opublikowanego App. Teraz ułóżmy to w znany programistom schemat środowisk — dev/staging/production — i zobaczmy, jak ma się on do Dev Mode i Store.

Najczęściej w głowie przydaje się taka macierz:

Developer Mode w istocie przykleja się do waszej infrastruktury dev lub staging: publikujecie tam tymczasowy URL, którego ChatGPT używa do testów. Konfiguracja Store wskazuje natomiast na już „dorosły” production‑URL.

W przyszłości, gdy będziemy mówić o deployu na Vercel i tunelach, ta macierz zamieni się w zestaw całkiem konkretnych kroków. Już teraz jednak warto trzymać w głowie prostą ideę: zawsze wiedzcie, gdzie trafia bieżące żądanie ChatGPT — do waszej piaskownicy dev czy do środowiska produkcyjnego, do którego chodzą użytkownicy.

8. Mały „kawałek kodu” o cyklu życia

Aby spiąć to z waszym podejściem TypeScript, napiszmy prosty typ, który odzwierciedla cykl życia App już nie na poziomie platformy, lecz waszego własnego tooling’u. Można go dodać do repozytorium, żeby nie zapominać o różnych stanach.

type AppLifecycleState = 'draft' | 'under_review' | 'published' | 'paused';

interface LifecycleSnapshot {
  id: string;
  name: string;
  state: AppLifecycleState;
  lastDeployedAt: Date | null;
  devUrl?: string;
  prodUrl?: string;
}

const giftGeniusLifecycle: LifecycleSnapshot = {
  id: 'giftgenius',
  name: 'GiftGenius – dobór prezentów',
  state: 'draft',
  lastDeployedAt: null,
  devUrl: 'https://dev.giftgenius.example.com',
};

Takiego obiektu nigdy nie wyślecie do ChatGPT, ale pomaga on zespołowi mieć wspólny kontekst. Można nawet zrobić prosty CLI, który pokazuje stan wszystkich waszych Apps, żeby nie mylić, gdzie jest szkic, a gdzie coś, co już znajduje się w Store.

W kolejnych modułach będziemy ciągle wracać do tego modelu cyklu życia: gdy będziemy konfigurować tunele i deploy na Vercel, projektować serwer MCP i scenariusze agentskie, planować przepływ commerce i przygotowanie do review w Store. Myślcie o Dev Mode i Store jak o dwóch biegunach jednego systemu: piaskownicy do eksperymentów i witrynie dla już „dorosłego” produktu.

9. Typowe błędy podczas pracy z Dev Mode i Store

Błąd nr 1: „Od razu do Store, a potem się zobaczy”.
Czasem kusi, aby jak najszybciej „zdobyć rynek” i wrzucić App do Store już na etapie pół‑działającego prototypu. To niemal gwarantuje negatywne opinie użytkowników, słabe statystyki użycia i dodatkowe pytania na review. Zdrowsze jest najpierw przeżyć kilka iteracji w Developer Mode, zebrać feedback od kolegów i znajomych, ustabilizować podstawowy UX i dopiero potem iść do Store.

Błąd nr 2: Mieszanie środowisk dev i production.
Typowy scenariusz: konfigurujecie Dev Mode na ten sam URL co production, a potem dziwicie się, że „kilka debugowych zmian” zobaczyli nagle prawdziwi użytkownicy. Rozdzielać dev‑ i prod‑URL trzeba tak samo starannie, jak w zwykłych usługach webowych. Jeśli w konfiguracji ChatGPT App widnieje production‑URL — nie używajcie go do „szybkich eksperymentów wieczorami”.

Błąd nr 3: Brak jasnego obrazu stanów.
Gdy deweloperzy nie wiedzą, w jakim stanie żyje App (Draft, Under review, Published, Paused), powstają dziwne sytuacje: ktoś w zespole myśli, że App jest już w Store, inny wciąż uważa go za lokalny prototyp. Warto choćby w README projektu opisać, gdzie teraz jest App i co trzeba zrobić, aby przejść do następnego etapu.

Błąd nr 4: Ignorowanie polityk i review do ostatniej chwili.
Niektóre zespoły piszą App „jakby to była po prostu strona”, a o politykach, uprawnieniach i wymaganiach Store przypominają sobie dzień przed wysyłką na review. W efekcie okazuje się, że trzeba poważnie przebudować zbieranie i przechowywanie danych, przepisać opisy i zawęzić prawa. Lepiej mieć ramy w głowie od początku i już w Dev Mode eksperymentować z uczciwymi, minimalnymi uprawnieniami.

Błąd nr 5: Brak osobnej strategii dla użytku wewnętrznego i zewnętrznego.
Jeśli App od początku powstaje jako wewnętrzne narzędzie firmowe, a potem chcecie zrobić z niego produkt publiczny, łatwo pomylić grupę docelową. Wewnątrz firmy można pozwolić sobie na mniej „błyszczący” UX i bardziej złożone scenariusze, we Store użytkownicy oczekują innego poziomu wygody. Brak świadomości, w jakim trybie jesteście teraz, sprawia, że publiczny App wygląda jak wewnętrzne narzędzie adminsko‑techniczne, a wewnętrzny pilotaż grzęźnie, bo zbyt wcześnie myślicie o globalnym Store.

Błąd nr 6: Brak powiązania między Dev Mode a obserwowalnością.
Developer Mode świetnie nadaje się do debugowania, ale trzeba z niego korzystać. Jeśli nie patrzycie w logi i nie zapisujecie, jakie dokładnie żądania ChatGPT wysyła do waszego App w środowisku dev, to później, na production, mogą czekać was niemiłe niespodzianki. Lepiej traktować Dev Mode jako poligon do nauki prawdziwych zachowań modelu i użytkowników, a nie tylko do sprawdzenia, że „widget się kompiluje”.