1. Wysokopoziomowe spojrzenie na proces review
Publikacja ChatGPT App w Store to nie „wrzuć link i zapomnij”, lecz w pełni żywy cykl. W uproszczeniu wygląda to tak: przygotowujesz App, wysyłasz na review, recenzenci sprawdzają go według swoich checklist, otrzymujesz uwagi, poprawiasz i wysyłasz ponownie. I tak kilka razy, aż wszystkim wszystko będzie odpowiadać.
Najwygodniej patrzeć na to jak na mały workflow:
flowchart TD A[Dev Mode / Internal beta] --> B[Submit to Store] B --> C[Under review] C -->|Approved| D[Published] C -->|Changes requested| E[Fixes & Iteration] E --> B D --> F[Updates] F --> C D --> G[Paused / Unpublished]
Na wczesnych etapach (Dev Mode, wewnętrzne beta‑testy) łapiesz problemy techniczne i UX. Gdy klikasz „Submit to Store”, zaczyna się bardziej formalne review: sprawdzane jest zgodność z polityką treści, uprawnienia, stabilność oraz to, co masz w liście i dokumentach prawnych.
Warto przyjąć filozofię: review to nie egzamin, który albo „zdasz” i już nigdy tam nie wrócisz, albo „obalisz”. To stały kanał informacji zwrotnej między tobą a platformą. Store chce, aby twój App był bezpieczny, zrozumiały i stabilny, a ty chcesz dostać dostęp do użytkowników i nie zostać zdjęty po tygodniu. Niespodzianka: wasze interesy w gruncie rzeczy są zbieżne.
2. Co wysyłasz na review
Zanim ktoś po stronie platformy otworzy twój App, wypełniasz dość standardowy zestaw elementów:
- Metadane App: nazwa, podtytuł, kategoria, ikona.
- Opis listingu: krótki i pełny opis, przykłady scenariuszy.
- Linki do Privacy Policy, Terms, Support/Contact.
- Ustawienia uprawnień: jakie dostępy prosi App (np. OAuth, zewnętrzne API, tryby płatności itp.).
- Czasem — opis scenariuszy testowych i kont dla recenzenta.
- Sam App: MCP‑serwer, UI‑bundle, system‑prompt i opisy tools, które platforma zna już z Dev Mode/production‑URL.
Technicznie na tym etapie masz już wdrożoną wersję produkcyjną (zwykle na Vercel lub podobnym), do której Store będzie się odzywał. To znaczy, że przycisk „Submit” nie dotyczy wdrożenia kodu, lecz zmiany jego statusu: „ten kod już działa na twojej produkcji, teraz prosimy go sprawdzić i wpuścić użytkowników”.
Aby spiąć wszystkie elementy, zwykle wygodnie mieć mały config w repozytorium, gdzie jawnie utrwalasz, co wchodzi w wersję „kandydata do review”. Na przykład prosta struktura TypeScript:
// config/release-candidate.ts
export const releaseCandidate = {
version: "1.0.0",
apiBaseUrl: process.env.API_BASE_URL,
enableCommerce: true,
privacyPolicyUrl: "https://example.com/legal/privacy",
termsUrl: "https://example.com/legal/terms",
supportUrl: "https://example.com/support",
};
Taki plik nie zastępuje samego formularza Store, ale pomaga twojemu zespołowi rozumieć, co dokładnie „sprzedajesz” recenzentom i użytkownikom.
3. Jak recenzenci patrzą na twój App
A więc wypełniłeś formularze, przygotowałeś linki i kliknąłeś Submit. Co dzieje się po drugiej stronie Store? Wyobraź sobie, że sam jesteś recenzentem. Nie widziałeś kodu, nie znasz całej historii projektu, ale masz checklistę i ograniczony czas. Zwykle App jest oceniany z kilku perspektyw.
Po pierwsze, sprawdzane jest dopasowanie do polityki treści i marki. Nie wolno oferować zakazanych kategorii, naruszać zasad dotyczących medycyny, prawa czy finansów bez odpowiednich zastrzeżeń i „human in the loop”. Nie wolno podszywać się pod OpenAI ani używać ich marki tak, jakby to był oficjalny produkt.
Po drugie, analizowane są uprawnienia. Jeżeli prosisz o dostęp do czegoś wrażliwego (profile użytkowników, płatności, zewnętrzne konto przez OAuth), zostaniesz zapytany: czy to naprawdę potrzebne? I czy użytkownik rozumie to na podstawie opisu i zachowania App? Idealny przypadek to minimalne uprawnienia odpowiadające opisanym scenariuszom.
Po trzecie, oceniane są UX i stabilność. App nie powinien przejmować całego ekranu ChatGPT: jeśli bez końca rozwija się do fullscreen z byle powodu, bez jasnego wyjaśnienia, to minus. Jeśli backend regularnie rzuca błędami, a narzędzia psują się co drugi raz, zaufanie także spada.
Wreszcie, sprawdzana jest uczciwość listingu: czy opis App pokrywa się z tym, co recenzent faktycznie widzi w czacie. Jeśli obiecujesz „błyskawiczny dobór idealnego prezentu i natychmiastowy checkout”, a w praktyce App trzy razy się wywraca na etapie wyszukiwania i nie potrafi finalizować zamówień, review zakończy się szybko i smutno.
Aby ułatwić pracę recenzentom, warto wcześniej przygotować im „trasę”: listę kroków, które warto wypróbować, oraz oczekiwane rezultaty. To samo przyda się do twojej regresji.
Najprostszy przykład takiego opisu w kodzie — struktura ze scenariuszami testowymi, na którą można się powołać w dokumentacji wewnętrznej:
// test/review-scenarios.ts
export const reviewScenarios = [
{
id: "gift-basic",
title: "Dobór prezentu bez zakupu",
steps: [
"Poproś: Dobierz prezent dla przyjaciela, lubi gry planszowe, budżet 50 $",
"Upewnij się, że App proponuje opcje i nie wymaga logowania",
],
},
{
id: "gift-checkout",
title: "Dobór prezentu z testowym checkoutem",
steps: [
"Wybierz dowolny prezent z listy",
"Przejdź do finalizacji, używając testowej karty",
],
},
];
Ta struktura nie trafia bezpośrednio do Store, ale dyscyplinuje zespół i pomaga później aktualizować opisy dla recenzentów i wsparcia technicznego.
4. Konta i dane testowe: bez nich review nie poleci
Gdy w grę wchodzą pieniądze, dane osobowe lub zewnętrzne konta, recenzenci oczekują, że zapewnisz bezpieczny sposób przejścia całego scenariusza bez używania ich prawdziwej karty, prywatnego maila ani realnego Slacka/Google/czegokolwiek.
Umownie można wyróżnić dwa duże typy jednostek testowych.
Pierwszy typ — testowi użytkownicy/organizacje w twoim systemie. Na przykład dla GiftGenius możesz założyć specjalną „organizację review” z wcześniej przygotowanym katalogiem demo i podpiętymi testowymi metodami płatności w trybie sandbox dostawcy płatności. Ważne, aby recenzent nie przechodził złożonego onboardingu: w idealnym przypadku dostaje login/hasło albo magiczny link i od razu trafia do gotowej piaskownicy.
Drugi typ — dane testowe zewnętrznych dostawców. Płatności z reguły mają tryb sandbox (test cards, test accounts). Jeśli twój App deleguje płatność przez ACP/Instant Checkout, musisz mieć pewność, że w review używa środowiska testowego i nikt nie płaci realnymi pieniędzmi. To dotyka architektury części commerce, ale idea jest prosta: dodać w backendzie flagę „review/test mode”.
W kategoriach kodu może to wyglądać jak prosta flaga środowiska i config:
// config/env.ts
export const env = {
nodeEnv: process.env.NODE_ENV,
reviewMode: process.env.REVIEW_MODE === "true",
paymentProviderEnv: process.env.REVIEW_MODE === "true" ? "sandbox" : "production",
};
A w miejscu, gdzie inicjalizujesz klienta systemu płatności:
// lib/payments/client.ts
import { env } from "@/config/env";
export const paymentClient = createPaymentClient({
environment: env.paymentProviderEnv, // "sandbox" lub "production"
apiKey: process.env.PAYMENT_API_KEY!,
});
Taki drobiazg bardzo ułatwia życie: możesz uruchamiać App w trybie maksymalnie zbliżonym do produkcji, ale recenzenci nie dotykają prawdziwych pieniędzy.
Warto osobno przemyśleć scenariusze testowe dla integracji typu Gmail, Slack, Notion itp. Tam, gdzie używany jest OAuth, review często oczekuje albo wspólnego konta demo, albo bardzo prostej instrukcji stworzenia testowego workspace. Staraj się unikać scenariuszy „napisz do supportu, a my coś ręcznie włączymy” — review bywa zautomatyzowane i ograniczone czasowo, nikt nie będzie czekał na twój mail.
5. Typowe uwagi z review i jak na nie reagować
Być może niezbyt miła wiadomość: szansa, że pierwszy przelot przez review będzie idealny, jest zbliżona do szansy, że programista napisał kod bez bugów. Czyli w okolicach zera. I to normalne.
Uwagi najczęściej mieszczą się w kilku przewidywalnych kategoriach.
Pierwsza kategoria — uprawnienia i prywatność. Na przykład prosisz o dostęp do e‑maila użytkownika, ale w listingu nie wyjaśniasz, po co. Albo w Privacy Policy piszesz, że „nie przechowujesz danych czatu”, a logi MCP‑serwera spokojnie zapisują całe żądanie wraz z PII. Recenzent może poprosić o doprecyzowanie dokumentów, zmianę zachowania App albo jedno i drugie.
Druga kategoria — UX i zachowanie w czacie. App może „przejmować” dialog: agresywnie otwierać fullscreen tam, gdzie wystarczy tryb inline, nie zostawiać tekstowego podsumowania po działaniach, nie dawać użytkownikowi jasnej drogi „powrotu do czatu”. W takich przypadkach najpewniej poproszą cię o uproszczenie UX i poszanowanie głównego interfejsu konwersacyjnego ChatGPT.
Trzecia kategoria — stabilność i błędy. Jeżeli przy typowych scenariuszach App regularnie zwraca „Error talking to app” albo wewnętrzne 500, review może zostać wstrzymane, dopóki nie pokażesz, że to przypadek jednostkowy, a nie norma. Oczekują nie tylko naprawy bugów, ale i minimalnej obserwowalności: logów, health checków, rozsądnych timeoutów.
Czwarta kategoria — uczciwość listingu i obietnic marketingowych. Jeżeli w opisie obiecujesz więcej, niż faktycznie potrafisz, recenzenci zwykle szybko to zauważają, zwłaszcza jeśli deklarujesz „gwarantowane rezultaty” w wrażliwych domenach. Korekta składa się wtedy z dwóch kroków: albo zmniejszasz obietnice, albo zwiększasz implementację (częściej to pierwsze).
Jak właściwie reagować na uwagi? Najważniejsze — traktować review jak partnerstwo, a nie „złych moderatorów”. W odpowiedzi warto:
- Wyraźnie uznać problem: „Tak, w bieżącej wersji App robi X, a w opisie jest Y”.
- Opisać, co już zmieniłeś: „Skorygowaliśmy listing i zaktualizowaliśmy Privacy Policy, doprecyzowując, że…”.
- W miarę możliwości dołączyć krótki opis scenariusza testowego, w którym recenzent zobaczy poprawkę.
Jeśli nie rozumiesz, dlaczego pojawiła się uwaga, lepiej zadać pytanie doprecyzowujące, niż zgadywać. Na przykład: „Czy dobrze rozumiemy, że główny problem polega na tym, że App automatycznie przełącza się w fullscreen bez prośby użytkownika?”.
6. Wewnętrzna lista kontrolna przed wysłaniem na review
Aby zmniejszyć liczbę iteracji, warto wprowadzić własną listę kontrolną „pre‑flight” w duchu modułów 7, 15–17. To nie jest lista „na odhaczenie”, tylko praktyczne narzędzie, które naprawdę przechodzisz przed każdym submitem.
Technicznie możesz nawet dołączyć tę checklistę do repo jako mały moduł JSON/TS i uruchamiać ją w README albo w pipeline.
Najprostszy wariant w TypeScript może wyglądać tak:
// tools/review-checklist.ts
export interface ChecklistItem {
id: string;
description: string;
done: boolean;
}
export const reviewChecklist: ChecklistItem[] = [
{
id: "ux-inline-first",
description: "Główne scenariusze App działają w trybie inline, fullscreen tylko tam, gdzie jest naprawdę uzasadniony.",
done: false,
},
{
id: "privacy-links",
description: "Linki do Privacy Policy, Terms, Support są ważne i otwierają się bez autoryzacji.",
done: false,
},
{
id: "permissions-minimal",
description: "Poproszono wyłącznie o minimalnie niezbędne uprawnienia; każde jest opisane w listingu.",
done: false,
},
];
A we własnych wewnętrznych narzędziach lub po prostu w konsoli możesz wypisywać tę listę i zaznaczać postęp. To oczywiście nie jest obowiązkowa automatyzacja, ale programiści tradycyjnie lepiej dogadują się z kodem niż z Google Docs, więc czemu nie użyć znanego sobie narzędzia.
7. Iteracje i wersjonowanie: życie po pierwszej publikacji
Druga niespodzianka: nawet po przejściu review i udostępnieniu App użytkownikom proces się nie kończy. Każda istotna aktualizacja może ponownie wywołać sprawdzenie, zwłaszcza jeśli zmieniasz uprawnienia, dodajesz nowe wrażliwe scenariusze lub radykalnie przebudowujesz UX.
Dlatego warto traktować ChatGPT App jak żywy produkt z normalnym procesem wydawniczym, a nie „ostatni strzał”.
Zwykle rozsądne minimum jest takie: masz wersję w kodzie (semver), dziennik zmian (changelog) i świadomość, które wydania pociągają za sobą konieczność ponownego review, a które — nie. Na przykład korekta literówek w UI, niezmieniająca zachowania App i uprawnień, może przejść po cichu, a przejście od „same rekomendacje” do „pełny checkout z płatnością” na pewno wymaga nowej uwagi.
W kodzie może to wyglądać jak prosta stała i obiekt ze zmianami:
// config/app-version.ts
export const appVersion = "1.1.0";
export const appChangelog = {
"1.1.0": [
"Dodano sandbox-checkout dla użytkowników testowych",
"Doprecyzowano opis uprawnień w listingu",
],
"1.0.0": ["Pierwsza publiczna wersja GiftGenius bez płatności"],
};
I tak, świetnie, jeśli synchronizujesz te notatki z tym, co piszesz w release notes Store. Wtedy i recenzentom, i użytkownikom łatwiej zrozumieć, co się wydarzyło.
8. Komunikacja z platformą: jak nie pokłócić się z recenzentami
Być może najbardziej niedoceniana umiejętność — normalna rozmowa z recenzentami. Z reguły feedback przychodzi w postaci zestawu tez: co jest nie tak, jakie punkty polityki naruszasz, które fragmenty UX budzą pytania. Dobra odpowiedź to nie „Nic nie rozumiecie”, lecz spokojna i konkretna wiadomość.
Warto pamiętać o kilku prostych zasadach.
Po pierwsze, jasność. Nie pisz elaboratów o tym, jak zbudowana jest wewnętrzna architektura twojego MCP‑serwera i dlaczego jest taka piękna. Recenzenta interesuje przede wszystkim doświadczenie użytkownika i zgodność z polityką. Wystarczy krótko opisać, co zmieniłeś i jak teraz można to sprawdzić.
Po drugie, przejrzystość. Jeśli problem jest trudniejszy niż „poprawiliśmy tekst” i wymaga większych przeróbek, uczciwiej napisać: „Ta uwaga dotyczy kluczowej części naszego checkout flow, potrzebujemy 1–2 tygodnie na poprawne wdrożenie zmian. Wyślemy zaktualizowaną wersję, gdy będzie gotowa”.
Po trzecie, pamięć. Uwagi z review warto zapisywać nie tylko w mailu lub wewnętrznym trackerze, ale i w formie krótkiej „decyzji” w dokumentacji: co konkretnie było zabronione i dlaczego. To pomaga nowym deweloperom i productowi nie wchodzić znów na te same miny. Tu może pomóc prosta wewnętrzna notatka w dokumentacji albo nawet sekcja README typu „Store Review Decisions”.
9. Powiązanie z architekturą i poprzednimi modułami
Warto spojrzeć na proces review jak na „całościową weryfikację” wszystkiego, co robiłeś w poprzednich modułach.
Bez modułów o bezpieczeństwie i uprawnieniach (7, 15) prawdopodobnie pojawią się pytania o dostępy, pracę z PII, OAuth i destructive actions.
Bez modułów o stabilności i obserwowalności (16, 17) nie będziesz w stanie sensownie odpowiedzieć, dlaczego App czasem się wywraca, a czasem nie, i jak to monitorujesz. Metryki i SLO przestają być teorią i stają się argumentami: „widzę p95 < 2 sekundy dla głównego narzędzia oraz error rate < 1 % w ostatnich N dniach”.
Bez modułów UX (8, 11) App może po prostu „psuć” czat: fullscreen tam, gdzie nie jest potrzebny, niejasne przejścia między trybami, brak tekstowego podsumowania. Recenzenci widzą to szybciej niż ty, bo testują wiele różnych App i dobrze czują, kiedy ktoś „przesadza”.
I wreszcie, bez dzisiejszego zrozumienia procesu review ryzykujesz utknąć na etapie „wysłaliśmy, odesłali, obraziliśmy się”. Lepiej traktować to jako kolejny cykl iteracji, bardzo podobny do wewnętrznej regresji, tylko z jeszcze jednym zainteresowanym uczestnikiem — platformą.
W efekcie, jeśli masz sensowną checklistę, konta testowe i tryb sandbox, podstawową obserwowalność oraz normalną komunikację z recenzentami, proces review przestaje być loterią. To po prostu kolejny iteracyjny cykl wokół twojego ChatGPT App — tak samo naturalny jak regresja przed wydaniem czy code review w zespole.
10. Typowe błędy przy przechodzeniu review
Błąd nr 1: Wysłać App „jak jest” bez wewnętrznej checklisty.
Wiele zespołów klika „Submit” zaraz po tym, jak App „zadziałał” w Dev Mode. W efekcie w review wychodzą podstawy: uszkodzone linki do Privacy/Terms, niedziałające scenariusze, brak kont testowych. Leczy się to prostą wewnętrzną checklistą, którą naprawdę przechodzisz przed każdym submitem (ważne linki, minimalne uprawnienia, działające kluczowe scenariusze) — przykład takiej checklisty omówiliśmy wyżej w rozdziale „Wewnętrzna lista kontrolna przed wysłaniem na review”.
Błąd nr 2: Ignorować konta testowe i tryby sandbox.
Wysyłanie na review App, który wymaga prawdziwej karty bankowej recenzenta — zły pomysł. Tak samo źle, jeśli checkout teoretycznie istnieje, ale recenzent nie może go w ogóle przetestować. Trzeba wcześniej zaplanować testowe organization/user w twoim systemie oraz tryb sandbox dostawcy płatności, spięty z REVIEW_MODE lub podobną flagą.
Błąd nr 3: „Wynegocjować” wyjątki zamiast naprawić problem.
Czasem deweloperzy zaczynają spierać się z recenzentem: „ale konkurencja też tak ma” albo „to ograniczenie platformy, nic nie możemy”. Taki styl rzadko pomaga. Znacznie skuteczniej przeformułować scenariusz, uprościć UX, zmniejszyć uprawnienia i poprawić listing tak, by uczciwie odzwierciedlał zachowanie App.
Błąd nr 4: Nie dokumentować uwag i decyzji.
Jeśli dostałeś komentarz z review i po prostu „naprawiłeś buga w kodzie”, nie zapisując, co dokładnie było niedozwolone, za pół roku ktoś w zespole zrobi to samo. Lepiej prowadzić mały rejestr decyzji review: „Nie wolno automatycznie przełączać się w fullscreen bez wyraźnego działania użytkownika”, „nie wolno przechowywać pełnych treści czatów dłużej niż N dni bez jasnego wskazania w Policy” itp.
Błąd nr 5: „Duże wydania” bez strategii etapowania.
Próba dodania w jednym wydaniu i płatności, i nowych uprawnień, i nowego UX, i przebudowanego backendu — to przepis na długie iteracje review. O wiele spokojniej wychodzić małymi krokami: najpierw rekomendacje bez płatności, potem sandbox‑checkout, a potem pełny flow płatności. Zmniejszasz ryzyka i jest mniej argumentów do dyskusji w review.
Błąd nr 6: Polegać na odbiorze Store zamiast na własnym QA i obserwowalności.
Czasem zespół podświadomie liczy, że recenzenci „przetestują za nich”. W efekcie review zamienia się w darmowe QA, ale opóźnia start o tygodnie. Zdrowiej traktować review jako finalny sanity check już dość dojrzałego produktu, który ma swoje testy, logi, metryki i zrozumiałe scenariusze.
GO TO FULL VERSION