Czym jest ChatGPT App i czym NIE jest

1. Wprowadzenie

Z perspektywy zwykłego dewelopera wszystko brzmi już trochę znajomo: jest nowe modne słowo — ChatGPT App, jest API, jest SDK, jest jeszcze kilka skrótów i wydaje się, że to „kolejny sposób na wywoływanie modelu AI”.

Problem w tym, że bez klarownej mapy pojęć ludzie zaczynają mylić ze sobą bardzo różne byty: stare ChatGPT-wtyczki, Assistants API, Custom GPTs i nowe ChatGPT Apps. W rezultacie ktoś oczekuje, że „wyklika” wszystko w UI jak Custom GPT jednego wieczoru, a finalnie musi postawić serwer MCP, napisać widżet w Next.js i myśleć o Store. I na odwrót: ktoś pisze skomplikowany backend, chociaż do jego zadania wystarczyłby prosty Custom GPT albo zwykła obudowa API.

Dlatego zacznijmy od tego, czym jest nowy ChatGPT App (i poukładajmy wszystko w głowie), a czym nie jest.

Krótka „historyczna” ewolucja integracji z LLM

Zanim przejdziemy do definicji, warto zobaczyć ewolucję podejść. To pomoże nie tylko wkuwać nowe słowa, ale zrozumieć, skąd w ogóle wziął się pomysł App wewnątrz ChatGPT.

Najpierw był klasyczny wariant „API wrapper”. Uruchamialiście własną aplikację webową lub bota, a gdzieś w backendzie wywoływaliście OpenAI API: przekazywaliście prompt, dostawaliście tekstową odpowiedź i pokazywaliście ją użytkownikowi. Cała logika, UI, autoryzacja i billing były po waszej stronie. ChatGPT jako produkt w ogóle tu nie uczestniczył.

Później pojawiły się ChatGPT Plugins.

To była pierwsza próba wbudowania zewnętrznych usług w sam interfejs ChatGPT. Wtyczka była opisana przez OpenAPI, ChatGPT mógł wywoływać jej endpointy, a wy odpowiadaliście JSON-em, który model przedstawiał użytkownikowi tekstem. Wtyczka nie miała własnego UI — co najwyżej Markdown, który model mógł pokazać w czacie. Dziś ten system uważa się za przestarzały.

Potem przyszły Custom GPTs (MyGPTs).

To kreator „własnej wersji ChatGPT” bez kodu: konfigurujecie prompty, podpinacie pliki, czasem — Custom Actions do HTTP-API. Wszystko żyje w interfejsie ChatGPT, ale UI jest ściśle standardowy, a integracje ograniczone możliwościami Actions.

I wreszcie jakościowy przełom — najnowsze ChatGPT Apps. Pojawia się bogaty UI (widżet wewnątrz czatu), standardowy protokół komunikacji z waszymi danymi i logiką backendową (MCP) oraz osobne miejsce w ekosystemie: Dev Mode, Store, uprawnienia, wbudowane płatności i tak dalej.

W momencie pisania tego kursu w Google Play było 4 miliony aplikacji, w Apple AppStore — 2 miliony, a w ChatGPT zaledwie 5. Nie 5 milionów, tylko zaledwie 5(!) aplikacji. A ChatGPT ma 800 milionów aktywnych użytkowników tygodniowo. Nigdy nie było tak łatwo wejść do top100 aplikacji i zarobić kilka milionów.

Jeśli was to zaciekawiło, przejdźmy głębiej do głównego pytania: czym właściwie jest to nowe ChatGPT App?

2. Zwięzła definicja ChatGPT App

W internecie jest kilka marketingowych opisów, ale że wszyscy tu jesteśmy z IT, przetłumaczę to na ludzki język.

ChatGPT App to aplikacja webowa, która uruchamia się wewnątrz ChatGPT i ma własny widżet UI. Aplikacja udostępnia ChatGPT zestaw narzędzi (funkcji) i danych oraz rejestruje się w katalogu aplikacji (App Store). Łączy interfejs konwersacyjny (czat) z graficznym UI i logiką backendową, komunikując się z platformą ChatGPT poprzez znormalizowane protokoły, takie jak MCP.

Co to nam daje:

Po pierwsze, „uruchamia się wewnątrz interfejsu ChatGPT”. Użytkownik nigdzie nie wychodzi z https://chatgpt.com/ ani z aplikacji mobilnej; UI waszej aplikacji jest osadzony w tym interfejsie jako widżet. Wasz widżet będzie wyświetlany bezpośrednio w strumieniu czatu.

Po drugie, „ma własny widżet UI”. To nie tylko tekst, który model wypisuje w czacie. Możecie renderować komponenty Reacta: karty, listy, formularze, mapy, odtwarzacze i inne przyjemności front-endowego życia. Technicznie to zwykła aplikacja Next.js działająca w piaskownicy i komunikująca się z ChatGPT przez obiekt window.openai oraz Apps SDK.

Po trzecie, „udostępnia ChatGPT zestaw narzędzi (funkcji) i danych”. Uruchamiacie w backendzie serwer MCP i rejestrujecie na nim narzędzia MCP waszego App — opisujecie działania, które wasza usługa potrafi wykonać: wyszukiwanie w katalogu, rezerwacje, analiza danych, generowanie raportów. ChatGPT widzi te narzędzia jako funkcje z JSON Schema i może je wywoływać wedle uznania.

Po czwarte, „rejestruje się w katalogu aplikacji”. App ma nazwę, ikonę, opisy, kategorie, uprawnienia, wersje i monetyzację. To nie „skrypcik na kolanie”, tylko pełnoprawny App w ekosystemie ChatGPT.

Bardzo ważna zmiana sposobu myślenia: nie piszecie „bota”, który sam wszystko załatwi. Opisujecie interfejs i możliwości (UI + narzędzia), a ChatGPT sam decyduje, kiedy ich użyć i jak wpleść je w dialog. Macie tylko częściową kontrolę nad całym scenariuszem.

Taki model ma dla was ogromny plus — ChatGPT sam proponuje użytkownikom instalację waszej aplikacji i sam decyduje, kiedy ją uruchomić. Tzn. koszt reklamy aplikacji wynosi $0. Milion instalacji waszej aplikacji kosztuje was $0. Przynajmniej jeśli będziecie jednymi z pierwszych.

Uruchomić własną ChatGPT-aplikację w 2025 roku — to jak kupić bitcoiny po $1. Decyzja należy do was.

3. Anatomia ChatGPT App: UI, narzędzia i kontekst

Aby się dalej nie pogubić, rozłóżmy App na trzy duże komponenty, które będą przewijać się przez cały kurs.

Pierwszy komponent — warstwa UI. To wasz widżet pisany zazwyczaj w React/Next.js z użyciem Apps SDK. Renderuje się wewnątrz ChatGPT, pokazuje listy prezentów, formularze rezerwacji, wykresy i inne elementy wizualne. Żyje w piaskownicy: nie może modyfikować wspólnego DOM‑u, nie może ot tak wchodzić do internetu i działa w granicach ograniczonego okna.

Drugi komponent — narzędzia, zasoby i prompty. Na poziomie protokołu to serwer MCP z opisanymi możliwościami: tools (działania), resources (dane) i prompts (szablony). Narzędzia są opisane schematami JSON, a model widzi je jako funkcje, które można wywołać, gdy to właściwe. W kolejnych modułach szczegółowo zobaczymy, jak dokładnie przebiega callTool, ale teraz warto zapamiętać: narzędzia to ręce i oczy waszego App w prawdziwym świecie.

Trzeci komponent — kontekst użycia. To wszystko, czym opisujecie swoje App dla modelu i użytkowników: systemowy prompt, opisy narzędzi, uprawnienia, grupa docelowa, kategorie w Store. Od tych metadanych zależy, kiedy GPT będzie proponował App, jakie zapytania uzna za relewantne i jakie działania są dozwolone.

Nieco później, gdy będziemy omawiać aplikację szkoleniową GiftGenius, zobaczycie te trzy warstwy na żywo: widżet UI z kartami prezentów i kreatorem pytań uściślających, narzędzia doboru i złożenia zamówienia po stronie MCP/backendu oraz kontekst — instrukcje systemowe, opisy, uprawnienia i kategorie w Store.

4. Porównujemy „aplikacje” ChatGPT

Skoro mamy już ogólne pojęcie i anatomię App, zróbmy krok wstecz i porównajmy go z „krewnymi”. To pomoże ostatecznie rozdzielić w głowie Apps, wtyczki, Assistants API i samo OpenAI API. Poniżej — tabela pomagająca trzymać te byty oddzielnie.

Dobra analogia, która wyraźnie pojawia się w oficjalnej dokumentacji: Assistants API — to gdy bierzecie „mózg GPT” i wbudowujecie go w swój produkt, a ChatGPT App — odwrotnie, gdy przenosicie swój produkt do interfejsu ChatGPT.

5. Czym ChatGPT App NIE jest

Przejdźmy teraz przez popularne nieporozumienia. To ważne, aby później nie projektować App jako czegoś innego.

ChatGPT App ≠ po prostu strona na Next.js

Intuicyjna skłonność front-endowca — traktować App jak „kolejne SPA”, tylko zamiast / macie „jakieś dziwne okno w ChatGPT”. To częściowo prawda, ale jest kluczowa różnica: nie działacie na własnej domenie i nie kontrolujecie całego UI, tylko wynajmujecie mały kawałek interfejsu u ChatGPT. Nie możecie przepisać nawigacji, postawić własnego bannera ponad wszystkim czy „zhakować” środowiska.

W naszym kursie będziemy traktować widżet jako izolowany komponent, a nie pełnoprawny serwis: ma twarde ograniczenia sieciowe, DOM i zasobowe, a cała ciężka praca trafia do backendu/MCP. Szczegółowo o piaskownicy porozmawiamy w ostatniej lekcji tego poziomu, tutaj wystarczy pamiętać, że to nie jest „kolejny hosting Next.js”.

Dla przykładu — fragment kodu. Tak wygląda klasyczny „API wrapper” wokół OpenAI w waszej aplikacji Next.js — to nie jest ChatGPT App:

// app/api/chat/route.ts — zwykły backend waszej strony, nie App
import OpenAI from "openai";
import { NextRequest, NextResponse } from "next/server";

const client = new OpenAI();

export async function POST(req: NextRequest) {
  const { message } = await req.json();
  const response = await client.responses.create({
    model: "gpt-5.2",
    input: [{ role: "user", content: [{ type: "text", text: message }] }],
  });
  return NextResponse.json({ reply: response.output[0].content[0].text });
}

Użytkownik tej aplikacji rozmawia z waszym backendem, a nie z ChatGPT. Cała logika UI i sesji — wasza. To świetny wariant dla funkcji AI wewnątrz własnego produktu, ale to nie jest ChatGPT App.

ChatGPT App ≠ stary ChatGPT Plugin

Słowo „wtyczka” trzeba wysłać do muzeum 2023 roku i używać go tylko do oznaczania starego systemu. Wtyczki dawały ChatGPT możliwość wywoływania waszych endpointów HTTP na podstawie specyfikacji OpenAPI, ale nie pozwalały budować bogatego UI: co najwyżej mogliście zwrócić Markdown, który model pokazywał w czacie.

Nowe Apps, w przeciwieństwie do wtyczek, potrafią renderować widżety Reacta, działać przez MCP, mieć uprawnienia i brać udział w scenariuszach finansowych. Dlatego myślenie o nich jako o „wtyczkach 2.0” to uproszczenie, które szybko obróci się przeciwko wam, gdy zaczniecie projektować UI i narzędzia.

ChatGPT App ≠ Assistants API

Assistants API rozwiązuje inny problem: jak dać waszemu produktowi (stronie, aplikacji mobilnej, narzędziu wewnętrznemu) inteligentnego asystenta opartego o GPT. Tam wszystko żyje „u was”, kontrolujecie UI, a GPT to usługa backendowa, z którą komunikujecie się przez API.

W przypadku ChatGPT App jest odwrotnie. UI i główne doświadczenie użytkownika należą do ChatGPT, a wy „wprowadzacie” tam swoją aplikację. Użytkownik nie widzi waszej domeny, widzi nazwę i ikonę App wewnątrz ChatGPT, a za tokeny zwykle płaci on sam przez swoją subskrypcję ChatGPT.

W skrócie: Assistants API — to GPT w waszym produkcie, ChatGPT App — wasz produkt w ChatGPT.

ChatGPT App ≠ po prostu Custom GPT

Custom GPTs to świetne narzędzie na szybki start: złożyliście prompt, podpięliście parę plików — i już macie „osobistego asystenta”. Ale UI jest standardowy, bez widżetów, a integracje przez Custom Actions są dość ograniczone; nie ma tam pełnego Apps SDK ani warstwy MCP.

ChatGPT App to już historia pro‑code. Piszecie widżet (zwykle w Next.js), stawiacie serwer MCP, konfigurujecie uwierzytelnianie, uprawnienia, płatności. Poziom elastyczności jest wyraźnie wyższy, ale i odpowiedzialność większa: za bezpieczeństwo, za UX i za przejście review przy rejestracji aplikacji.

Praktyczna strategia, którą mogę polecić biznesowi: użyć Custom GPT jako szybkiego wejścia marketingowego (prosty asystent w GPT Store), a równolegle rozwijać pełnoprawny App na Apps SDK do poważnych scenariuszy i przyszłej monetyzacji.

ChatGPT App ≠ „po prostu kolejny bot”

I na koniec ważny aspekt psychologiczny. ChatGPT App to nie „kolejny czat‑bot”. To produkt z cyklem życia: jest Dev Mode, review, wersje, ograniczenia, analityka i scenariusze płatnicze. Myślenie o nim jak o „bocie do dema” to pewny sposób, by mocno niedoszacować wysiłek, zawalić prawdziwe wdrożenie i nie zarobić swoich milionów.

6. Typy aplikacji ChatGPT

Aby lepiej rozumieć, co budujecie, warto mieć zgrubną typologię ChatGPT Apps. W naszym kursie będziemy mówić o czterech głównych fokusach i używać dla nich krótkich angielskich etykiet: UI-heavy, tool-first, commerce-oriented i data/analytics.

• Pierwszy typ — UI‑heavy lub UI‑first aplikacje. Główna wartość to interfejs wizualny: kreatory, konfiguratory, złożone formularze, canvas. Przykłady: dobór ubezpieczenia z dziesiątkami parametrów, konfigurator designu, wizualizacja danych.
• Drugi typ — aplikacje Tool‑first. Najważniejsze są tu nie UI, lecz narzędzia. App udostępnia modelowi potężny zestaw funkcji, a większość doświadczenia użytkownika formułuje sam ChatGPT, wstawiając wyjaśnienia tekstowe i czasem minimalny UI. Przykład — App dający GPT dostęp do wewnętrznej knowledge base firmy: model sam decyduje, kiedy i jak wywołać wyszukiwanie i jak wyjaśnić wyniki użytkownikowi.
• Trzeci typ — aplikacje Commerce‑oriented. Środek ciężkości jest na sprzedażach, subskrypcjach, rezerwacjach. App jest zintegrowany z Agentic Commerce Protocol (ACP), potrafi finalizować zakupy, pracować z koszykiem i Instant Checkout, wiązać zamówienia z użytkownikami.
• Czwarty typ — aplikacje Data/analytics. Koncentrują się na podłączaniu źródeł danych i analityce: raporty, dashboardy BI, analiza logów i metryk, praca z przesłanymi plikami.

Ten sam pomysł można zrealizować w różnych stylach. Na przykład dobór prezentów może być czysto Tool‑first (model sam formułuje wyjaśnienia, a App jedynie zwraca JSON z listą pomysłów) albo UI‑heavy (bogaty widżet z filtrami, kartami produktów, porównaniem wariantów).

7. Nasz projekt edukacyjny: GiftGenius

Wszystko, co będziemy robić na kursie, dobrze jest powiązać z jedną „przewodnią” aplikacją. Dlatego w trakcie kursu będziemy pisać własne App: GiftGenius — aplikację do doboru prezentów i finalizowania zakupów przez ChatGPT. Będziemy do niego ciągle wracać.

Z punktu widzenia typologii GiftGenius to przede wszystkim App zorientowany na komercję (commerce‑oriented) z elementami UI‑heavy. Użytkownik pisze w ChatGPT coś w stylu: „Potrzebny prezent dla znajomego z IT, budżet 50–70 dolarów”, model AI decyduje podłączyć GiftGenius, App pokazuje widżet z pytaniami doprecyzowującymi, doborem prezentów i ostatecznie z finalizacją zamówienia przez ACP.

Żeby już teraz zacząć myśleć o tym w kategoriach TypeScriptu, możemy naszkicować najprostszy model domeny, który będzie nam dalej towarzyszył:

// gift-types.ts — uproszczony model domenowy GiftGenius
export type GiftIdea = {
  id: string;
  title: string;
  priceUsd: number;
  tags: string[];      // zainteresowania obdarowanego
  occasion: string;    // okazja: birthday, wedding itd.
};

Na razie to po prostu typ, niepowiązany z żadnym SDK. Ale w trakcie kursu zobaczycie, jak takie modele domenowe przenikają do narzędzi MCP, do widżetu UI, a nawet do warstwy commerce.

8. Jak użytkownik widzi ChatGPT App w rozmowie

Choć temat „user flow” będzie główny w trzeciej lekcji, ważne jest od razu naszkicować ogólny obraz, aby rozumieć, po co w ogóle potrzebny jest UI i jak App pojawia się w dialogu.

Użytkownik rozmawia z ChatGPT jak zwykle: pisze wiadomości, zadaje pytania, prosi o pomoc. ChatGPT z kolei przy każdej wypowiedzi decyduje, co zrobić: odpowiedzieć samodzielnie, wywołać jakieś narzędzie, pokazać lub zaktualizować widżet waszego App, zaproponować użycie App, jeśli jest relewantny do kontekstu.

Na przykład użytkownik pisze: „Potrzebuję prezentu na rocznicę ślubu, budżet do 100 dolarów, mąż lubi gry planszowe”. Model widzi, że ma App GiftGenius, który potrafi dobierać prezenty według takich kryteriów. Może pójść dwiema drogami:

1. Najpierw zaproponować użytkownikowi skorzystanie z GiftGenius, pisząc coś w rodzaju: „Mogę podłączyć App GiftGenius, aby dobrać kilka opcji. Uruchomić go?”.
2. Od razu wywołać narzędzia App i wyświetlić widżet z już wypełnionymi polami, pokazując użytkownikowi propozycje.

To wszystko dzieje się bez waszego bezpośredniego if user_said_gift then call_app(). Opisujecie możliwości App, a model uczy się z nich korzystać. Dlatego tak ważne są precyzyjne opisy, ograniczenia i przemyślany UX — w przeciwnym razie GPT będzie albo nadużywał waszego App, albo przeciwnie, nigdy go nie dotknie.

Dla przejrzystości można to sobie wyobrazić jako diagram:

flowchart TD
  U[Użytkownik w ChatGPT] -->|wiadomość| G[Model GPT]
  G -->|decyzja: użyć App?| A[Twoje ChatGPT App]
  A -->|widżet| W[UI w czacie]
  A -->|tools/MCP| B[Wasz backend / MCP]
  B --> A --> G --> U

Szczegółowo o tym, jak GPT podejmuje decyzję o wezwaniu App, będziemy mówić w tematach o narzędziach i system prompt, ale już teraz warto rozumieć: to współpraca, a nie sterowanie imperatywne.

9. Mini‑ćwiczenie: wasz pomysł na App

Aby materiał nie pozostał abstrakcyjną teorią, warto już teraz wymyślić pomysł na własny App, który będziecie mentalnie rozwijać razem z GiftGenius.

Spróbujcie sformułować w jednym zdaniu, co robi wasza aplikacja wewnątrz ChatGPT. Na przykład: „App pomaga deweloperom oceniać złożoność zadań i rozbijać je na podzadania” albo „App dobiera trasy podróży z uwzględnieniem pogody i budżetu”.

Dalej warto szczerze odpowiedzieć sobie na dwa pytania. Po pierwsze, do którego typu z naszej typologii jest bliżej: UI‑heavy, tool‑first, commerce‑oriented czy data/analytics. Po drugie, czy to naprawdę ChatGPT App czy w gruncie rzeczy tylko bot na waszej stronie albo kolejny Custom GPT. Jeśli wszystko, czego potrzebujecie, to nieco wygodniej wołać OpenAI API w backendzie, być może pełnoprawny App nie jest wam potrzebny.

Takie mini‑analizy to dobry sposób, by zaoszczędzić sobie parę miesięcy pracy nad nie tym produktem.

10. Typowe błędy w rozumieniu ChatGPT App

Błąd nr 1: Nazywanie wszystkiego „wtyczką”.
System wtyczek to etap historyczny z roku 2023. Nowa generacja integracji to Apps na Apps SDK + MCP. Jeśli mentalnie trzymać się terminu „wtyczka”, łatwo niedoszacować rolę UI, piaskownicy, Store i całego cyklu produktowego. W tym kursie słowa „wtyczka” używamy tylko dla starego systemu, a przez App rozumiemy zawsze nową generację aplikacji.

Błąd nr 2: Oczekiwać pełnej kontroli nad GPT.
Czasem deweloper przychodzi z nastawieniem „napiszę App i model będzie robił dokładnie to, co mu powiem”. W ekosystemie ChatGPT działa to inaczej: opisujecie swoje możliwości i intencje, ale model sam decyduje, kiedy wywoływać narzędzia, kiedy pokazywać widżet, a kiedy po prostu odpowiedzieć tekstem. Jeśli próbować projektować App jak klasyczne SPA z twardym scenariuszem, skończy się to bolesnym rozczarowaniem.

Błąd nr 3: Mylić ChatGPT App z Assistants API.
Bardzo częsta sytuacja: ktoś chce „bota w swoim produkcie”, ale z przyzwyczajenia patrzy w stronę Apps SDK, choć dużo prościej i logiczniej byłoby użyć Assistants API. W efekcie traci siły na widżet w ChatGPT, którego jego użytkownicy w ogóle nie potrzebują. Właściwe rozróżnienie jest proste: jeśli użytkownicy przychodzą na waszą stronę lub do waszej aplikacji, myślcie o Assistants API; jeśli chcecie przyjść do użytkowników w ChatGPT, myślcie o ChatGPT App.

Błąd nr 4: Uważać App za „jeszcze jeden frontend” bez uwzględnienia piaskownicy.
Gdy deweloper próbuje używać Apps SDK jak zwykłego frontendu Next.js i ignoruje ograniczenia piaskownicy (ograniczony dostęp do sieci, DOM, zasobów), szybko zderza się z tym, że „nic nie działa jak na mojej stronie”. Ważne jest z góry przyjąć, że widżet to izolowany komponent, a cała ciężka integracja i przechowywanie sekretów muszą być wyniesione do backendu/MCP.

Błąd nr 5: Przeceniać Custom GPT i nie doceniać Apps SDK (albo odwrotnie).
Custom GPTs i Apps to nie „albo/albo”, lecz różne poziomy dojrzałości. Często właściwa strategia to używać obu: Custom GPT jako szybkie wejście i marketing, App jako poważny produkt z bogatym UI i commerce. Kiedy deweloper oczekuje od Custom GPT możliwości poziomu Apps SDK albo odwrotnie, ciągnie Apps SDK tam, gdzie wystarczyłby Custom GPT, tylko komplikuje sobie życie.