Developer Mode vs Store

1. Einführung

In den vorherigen Vorlesungen haben wir bereits darüber gesprochen, was eine ChatGPT App ist, aus welchen Schichten sie besteht und wie sie sich von den alten Plugins und einfachen Bots auf der OpenAI API unterscheidet. Jetzt wenden wir uns dem zweiten wichtigen Thema zu – dem Lebenszyklus eines solchen Produkts.

Wenn Sie seit einigen Jahren Webservices schreiben, schreckt Sie das Wort „Lifecycle“ nicht. Jedes Produkt hat einen einfachen Weg: „lokal implementiert → auf Staging ausgerollt → auf Production ausgerollt → manchmal alles kaputt gemacht → repariert“. In der ChatGPT-Ökosystemwelt mit der App ist es ähnlich, aber mit Nuancen: Es gibt einen Dev Mode innerhalb von ChatGPT und eine separate Entität – den Store.

Wichtig ist, zwei Ebenen klar zu trennen:

1. Wo Ihr Code physisch läuft: lokaler Next.js‑Server, Vercel, irgendein Kubernetes‑Cluster und so weiter. Das ist Ihre Welt – dort sind Sie Herr im Haus.
2. Wie ChatGPT Ihre App sieht: als Satz von Metadaten, URL und Berechtigungen, die Sie entweder im Developer Mode verbinden oder als fertiges Produkt im Store veröffentlichen können. Das ist die Welt von OpenAI – mit eigenen Regeln, Review und Nutzern.

Diese Vorlesung geht genau um die zweite Ebene. Wir orientieren uns an Ihrem gewohnten Umgebungsmodell (dev / staging / prod), betrachten es aber durch die Brille von ChatGPT. Unser Ziel: dass Sie jederzeit ein paar Fragen beantworten können. Welcher Code läuft gerade in meiner App? Wer sieht sie? Wie experimentiere ich sicher? Und was bedeutet überhaupt „die App im Store aktualisieren“?

2. Developer Mode: persönliche Sandbox innerhalb von ChatGPT

Beginnen wir mit dem Angenehmsten für Entwickler: einer Sandbox, in der man alles kaputtmachen kann, ohne damit (fast) jemanden zu schmerzen.

Developer Mode ist ein spezieller Modus in ChatGPT, in dem Sie Ihre ChatGPT Apps direkt über eine URL verbinden können – ohne Review, ohne die App im Store zu veröffentlichen und ohne sie der ganzen Welt zu zeigen. Vom Gefühl her ähnelt das localhost:3000 im Browser, nur eben in der Welt von ChatGPT.

Wie sieht das konzeptionell aus

Am einfachsten lässt sich das so vorstellen:

flowchart TD
    User("ChatGPT UI (Dev Mode)")
    AppConfig["Dev-Konfiguration der App (URL + Metadaten)"]
    AppServer["Ihr App-Server (Next.js + Apps SDK)"]

    User -->|Chat-Anfrage| ChatGPTCore[GPT]
    ChatGPTCore -->|App erforderlich| AppConfig
    AppConfig --> AppServer
    AppServer -->|UI/Tools| ChatGPTCore
    ChatGPTCore --> User

Sie sagen als Entwickler in den Einstellungen des Developer Mode zu ChatGPT: „Hier ist meine App, hier ist ihre URL, hier, wie sie heißt und was sie kann.“ ChatGPT betrachtet diese URL fortan als Quelle Ihrer Anwendung. Solange Sie die App nicht im Store einreichen, sehen sie nur Sie (und ggf. weitere Teammitglieder, wenn Sie sie als Entwickler einladen).

Technische Anschlussdetails (HTTPS‑Tunnel, Vercel und andere Freuden) besprechen wir später. Wichtig ist hier die Idee: Dev Mode ist so etwas wie eine „dynamische Verknüpfung“ auf Ihren Dev‑Server, den ChatGPT aufrufen kann.

So aktivieren Sie den Developer Mode

Damit Sie die Möglichkeit haben, Ihren lokalen Server an die ChatGPT-Oberfläche "anzubinden", müssen Sie den entsprechenden Schalter in den Einstellungen aktivieren.

• Folgen Sie dem Link https://chatgpt.com/#settings/Connectors/Advanced oder gehen Sie zu Settings -> Connected apps -> Advanced.
• Developer Mode - ON

Sobald Sie dies getan haben, erscheint die Schaltfläche Create App.

Worin sich der Dev Mode von Production unterscheidet

Der Unterschied ähnelt dem zwischen Dev‑ und Production‑Umgebung im klassischen Web, es gibt aber ein paar spezifische Punkte.

Erstens die Sichtbarkeit. Ihre App ist im Dev Mode in der Regel für normale ChatGPT-Nutzer nicht zugänglich. Sie wird nur von Ihnen und ggf. Mitgliedern Ihrer Organisation mit entsprechenden Rechten gesehen. Sie können experimentieren, ohne dass zufällig jemand über einen halbfunktionalen UX stolpert.

Zweitens Stabilität und Experimente. Im Dev Mode können Sie den Code alle zwei Minuten ändern, einen lokalen Server starten, beenden, den Tunnel neu hochfahren. ChatGPT versucht, die angegebene URL zu erreichen, nimmt es aber nicht übel, wenn Sie gelegentlich eine 500 zurückgeben oder gar nicht antworten – dafür ist es Dev.

Drittens Berechtigungen und Richtlinien. Im Dev Mode ist es leichter, verschiedene Konfigurationen auszuprobieren. Wichtig bleibt aber: Inhalts‑ und Basissicherheitsrichtlinien sind auch im Dev‑Modus nicht ausgeschaltet – ChatGPT lässt Sie nicht plötzlich zur „Hacker‑App für alles“ werden. Die Store‑Review‑Leitplanken greifen hier jedoch noch nicht: Ein perfektes Listing, ein schönes Logo usw. sind noch nicht nötig.

Und schließlich ist es im Dev Mode meist einfacher zu diagnostizieren, wo es hakt. Sie können die Logik schnell ändern, sehen, welche Requests von ChatGPT an Ihren Server gehen, und das Verhalten korrigieren, ohne über „Nutzermigrationen“ nachdenken zu müssen.

Wir haben uns den Dev Mode bereits als persönliche Sandbox für Apps angesehen und schon ein wenig in Richtung Store geblickt. Fassen wir das nun als verständliche „Zustandsmaschine“ für den Lebenszyklus der App zusammen.

3. Zustände der ChatGPT App: vom Entwurf bis zur Depublikation

Formalisieren wir das als verständliche „Zustandsmaschine“ für Ihre App. Wir sprechen grob über vier Hauptzustände: Draft / Dev‑only, Under review, Published und Paused/Removed.

Zustandsmaschine des Lebenszyklus

Versuchen wir, das als Diagramm darzustellen:

stateDiagram-v2
    [*] --> Draft

    Draft: Dev Mode / Entwurf
    Review: Under review (Store)
    Published: Im Store, für Nutzer verfügbar
    Paused: Paused / Removed

    Draft --> Review: Zur Prüfung einreichen
    Review --> Draft: Abgelehnt / zur Überarbeitung zurück
    Review --> Published: Genehmigt
    Published --> Paused: Pausieren / entfernen
    Paused --> Draft: Arbeit im Dev‑Modus fortsetzen
    Draft --> Published: Interner Rollout ohne Store (für die Organisation)

Im Zustand Draft existiert Ihre App nur als Dev‑Ressource. Sie können sie im Developer Mode verbinden, verschiedene Features testen, sie aber nicht im Store zeigen.

Wenn Sie entscheiden, dass die App bereit für Nutzer ist, reichen Sie sie „zum Review“ ein – das ist der Zustand Under review. Dort prüft OpenAI (oder ein internes Review‑System Ihrer Organisation) die Richtlinienkonformität, Stabilität, Basissicherheit und den angemessenen UX.

Wenn alles passt, landet die App im Zustand Published: Sie erscheint im Store oder wird für Nutzer Ihrer Firma verfügbar (im Unternehmensszenario). Ab diesem Moment kommen echte Nutzer, und alles, was Sie am Code und an der Konfiguration ändern, will sorgfältiger geplant sein.

Wenn Sie vorübergehend nicht möchten, dass die App verfügbar ist, können Sie sie in den Zustand Paused/Removed versetzen. In Paused ist sie für neue Nutzer verborgen, kann aber für bestehende Sessions weiterlaufen oder vollständig deaktiviert sein – die Details hängen von der Plattform und den Einstellungen ab.

4. Store: wenn Ihre App zum Produkt wird

Developer Mode ist Ihre private Garage. Der Store ist das offizielle Autohaus. Hier kommen Nutzer, Bewertungen, Listing‑Regeln und Reviews ins Spiel.

Was sich ändert, wenn Sie in den Store gehen

Erstens und vor allem: Ihre App wird zum „Produkt“. Sie erhält ein Listing: Name, Beschreibung, Icon, Kategorien, manchmal Start‑Prompts für den Dialog. Anhand dieser Metadaten wird der ChatGPT Store Ihre Anwendung finden und empfehlen, und das Modell versteht, in welchen Szenarien die App relevant ist.

Zweitens Review und Richtlinien. Bevor die App im Store erscheint, wird sie auf Sicherheits-, Inhalts- und UX‑Anforderungen geprüft. Das heißt:

• Sie dürfen nicht heimlich unnötige personenbezogene Daten sammeln;
• Sie dürfen nichts versprechen, was die App nicht leistet;
• Sie dürfen nicht außerhalb der zulässigen Inhaltskategorien agieren.

Wir sprechen in späteren Vorlesungen noch ausführlich über Richtlinien und Sandbox, aber schon jetzt ist es hilfreich, den Store als Ort zu begreifen, an den Sie nur relativ „wohl erzogene“ Versionen Ihrer App bringen.

Drittens Verantwortung für Stabilität. Im Dev Mode sind Ausfälle Ihr Problem. Im Store erwartet man von Ihrer App angemessene Verfügbarkeit, vernünftige Latenz und keine „roten Todesbildschirme“ im Widget. In späteren Modulen sprechen wir über SLOs, Metriken und Store‑Reviews genau in diesem Kontext.

Versionen: Dev vs Production

Typische Frage: „Wenn ich den Code aktualisiere – was sieht der Nutzer?“ In der Welt der ChatGPT Apps ist es hilfreich, zwei „Zweige“ gleichzeitig zu denken:

• Dev‑Zweig, der mit dem Developer Mode verbunden ist und auf einen Dev‑Server zeigen kann, der neben Ihrer IDE läuft;
• Production‑Zweig, der mit der veröffentlichten Konfiguration im Store assoziiert ist und auf eine stabile URL zeigt.

Architektonisch lässt sich das sogar mit einem kleinen TypeScript‑Typ in Ihrem Projekt ausdrücken:

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',
};

In der Praxis hält nicht Ihr Code die Konfiguration, sondern die ChatGPT-Plattform. Solche Strukturen helfen jedoch, im Kopf zu behalten, dass es zwei unterschiedliche „Abbilder“ derselben App sind.

Ein Release der ChatGPT App ähnelt eher einem Release in Apples App Store als einem Website‑Update. Ihre Widgets und MCP‑Tools werden bei jedem App‑Release gecacht. Und das Review kann zwei Wochen dauern. Also kein „wir schieben’s schnell in Production und testen dort weiter“. Sie sollten bereits eine vollständig getestete und stabile Anwendung ins Review geben.

5. Organisatorischer Kontext: persönlicher Account vs Unternehmen

Wir haben die App bereits in Dev‑ und Production‑Zweige getrennt und gesehen, wie sich das im Store widerspiegelt. Eine weitere wichtige Dimension des Lebenszyklus ist, in welchem organisatorischen Rahmen sie „lebt“.

Im einfachsten Fall bauen Sie die App als Privatperson in Ihrem persönlichen ChatGPT Plus. Dann ist der Dev Mode nur Ihrer, und der Store läuft ebenfalls unter Ihrem Account. Alles recht unkompliziert: für sich gebaut, veröffentlicht, die Welt erfreut.

Sehr häufig leben ChatGPT Apps jedoch im Unternehmenskontext. Dann kommen weitere Rollen hinzu. Es gibt Organisations‑Admins, die entscheiden, welche Apps den Mitarbeitenden zur Verfügung stehen, welche blockiert werden und welche nur einer Pilotgruppe erlaubt sind. Ihre App kann nicht für die ganze Welt, sondern nur für eine bestimmte Firma – oder sogar nur für bestimmte Abteilungen darin – veröffentlicht werden.

In einem solchen Szenario kann der Lebenszyklus so aussehen: Zuerst existiert die App nur als Dev‑Projekt im Team, dann entsteht ein „internes Production“ – z. B. nur für den Vertrieb als Pilot nutzbar. Erst danach, wenn alles gut läuft, entscheiden Sie sich, die App in den globalen Store zu schicken, um sie zu einem externen Produkt zu machen.

Architektonisch ist das wichtig, weil Sie die App so entwerfen müssen, dass sie sowohl als internes Werkzeug als auch als öffentliches Produkt funktioniert. Manchmal bedeutet das Feature‑Flags, Betriebsmodi „nur für interne Nutzer“ und separate Authentifizierungs‑Einstellungen.

6. Praxisbeispiel: Lebenszyklus von GiftGenius

Damit das Gesagte nicht abstrakt bleibt, betrachten wir die hypothetische App GiftGenius – ein Assistent für die Geschenkauswahl, der uns durch den Kurs begleiten wird.

Phase 1. Idee und grober Prototyp im Dev Mode

Sie entscheiden sich für GiftGenius: eine App, die den Nutzer fragt, für wen ein Geschenk gedacht ist, welches Budget zur Verfügung steht und welche Interessen der Empfänger hat, und dann Optionen vorschlägt – basierend auf Ihrem Produktkatalog.

Im ersten Schritt:

1. Starten Sie ein einfaches Next.js‑Projekt mit einem minimalen Widget.
2. Aktivieren Sie den Developer Mode in ChatGPT und fügen Sie die URL Ihres Dev‑Servers hinzu.
3. Führen Sie einige Testdialoge: Bitten Sie GPT: „Hilf mir, ein Geschenk für einen Gamer‑Freund bis 50 $ auszuwählen“, und beobachten Sie, wie es Ihre App aufruft, das Widget rendert und wie der UX wirkt.

An diesem Punkt denken Sie noch nicht über den Store, Reviews oder schöne Icons nach. Ihre Aufgabe ist es, sich und dem Team zu beweisen, dass die Idee grundsätzlich funktioniert und dass die ChatGPT-Plattform das gewünschte Szenario ermöglicht.

Phase 2. Festigung des Prototyps und interne „Alpha“

Wenn der Basisszenario tragfähig ist, beginnt die „Festigung“. Sie:

• bringen die Logik in eine halbwegs klare Struktur;
• denken darüber nach, welche Berechtigungen und Daten die App wirklich braucht;
• prüfen, wie sich die App bei Fehlern verhält (z. B. wenn der Produktkatalog nicht antwortet).

Noch immer im Dev Mode, aber nicht mehr allein: Sie fügen Kolleginnen und Kollegen als Entwickler oder Tester hinzu, damit sie die App ebenfalls in ihrem ChatGPT verbinden können. Der Lebenszyklus dreht sich weiterhin um den Zustand Draft: Sie aktualisieren den Code schnell, probieren verschiedene UX‑Muster aus und diskutieren Feedback im Team.

Phase 3. Vorbereitung auf den Store und das Review

An diesem Punkt sagen Sie: „Ja, GiftGenius ist bereits vorzeigbar genug für externe Nutzer.“ Der Fokus verschiebt sich nun vom Code zur Produktverpackung:

• Sie schreiben eine ehrliche, verständliche Beschreibung der App;
• konfigurieren Berechtigungen: erklären, auf welche Daten die App zugreift und warum;
• stellen sicher, dass der UX nicht irreführt und die App nichts Unmögliches verspricht.

Das ist der Übergang von Draft zu Under review. Sie reichen die App zum Review ein; für eine Weile lebt sie in diesem Zwischenzustand. Vielleicht kommen Rückmeldungen: Datenschutz präzisieren, Formulierungen anpassen, Berechtigungen einschränken. Sie gehen zurück in Draft, arbeiten nach und schicken erneut ein.

Phase 4. Veröffentlichung und „richtiges Leben“

Nach der Genehmigung landet Ihr GiftGenius im Zustand Published. Nutzer können ihn im Store finden, ChatGPT kann ihn bei relevanten Anfragen vorschlagen, und Sie sammeln echtes Feedback, beobachten die Nutzung und denken über Skalierung nach.

Ab jetzt ist jede Codeänderung nicht mehr „mal eben schnell eine Funktion ergänzen“. Es ist ein Mini‑Release. Sie müssen über Rückwärtskompatibilität nachdenken, Migrationen planen, nach Möglichkeit zuerst die Dev‑Version ändern, prüfen und erst dann die Production‑Konfiguration aktualisieren.

Bei Bedarf können Sie die App vorübergehend auf Paused setzen – etwa wenn Sie eine kritische Schwachstelle gefunden haben oder Ihr Backend der Last nicht gewachsen ist. Ideal ist jedoch, die Published‑Variante schrittweise weiterzuentwickeln, ohne die Dev‑Umgebung für Experimente zu vernachlässigen.

7. Wie Entwickler über Umgebungen denken sollten: dev, staging, production + Dev Mode

Am Beispiel GiftGenius sind wir vom Dev‑Mode‑Prototyp zur veröffentlichten App gegangen. Bringen wir das nun in das gewohnte Umgebungs‑Schema – dev/staging/production – und betrachten, wie es sich zum Dev Mode und dem Store verhält.

Praktisch ist folgende Matrix im Kopf:

Der Developer Mode klebt im Grunde an Ihrer Dev‑ oder Staging‑Infrastruktur: Sie veröffentlichen dort eine temporäre URL, die ChatGPT für Tests nutzt. Die Store-Konfiguration wiederum verweist auf einen erwachsenen Production‑URL.

Wenn wir später über Deployments auf Vercel und Tunnel sprechen, wird diese Matrix zu konkreten Schritten. Schon jetzt hilft die einfache Idee: Machen Sie sich immer klar, wo sich die aktuelle Anfrage von ChatGPT befindet – in Ihrer Dev‑Sandbox oder in der produktiven Umgebung, die echte Nutzer verwenden.

8. Ein kleines „Stück Code“ zum Lebenszyklus

Um das mit Ihrem vertrauten TypeScript‑Denken zu verknüpfen, schreiben wir einen einfachen Typ, der den Lebenszyklus der App nicht auf Plattform‑, sondern auf Tooling‑Ebene abbildet. Den kann man ins Repository legen, um die verschiedenen Zustände präsent zu halten.

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 – Geschenkempfehlungen',
  state: 'draft',
  lastDeployedAt: null,
  devUrl: 'https://dev.giftgenius.example.com',
};

So ein Objekt schicken Sie nie an ChatGPT, aber es hilft dem Team, denselben Kontext zu teilen. Man kann sogar ein kleines CLI bauen, das den Zustand all Ihrer Apps anzeigt, damit nicht verwechselt wird, was ein Entwurf ist und was bereits im Store steckt.

In den nächsten Modulen kommen wir immer wieder auf dieses Lebenszyklus‑Modell zurück: wenn wir Tunnel und Deployment auf Vercel aufsetzen, den MCP‑Server und agentische Szenarien entwerfen, Commerce‑Flows planen und die Vorbereitung auf das Review im Store durchgehen. Denken Sie an Dev Mode und Store als zwei Pole eines Systems: eine Sandbox für Experimente und eine Auslage für das gereifte Produkt.

9. Häufige Fehler beim Arbeiten mit Dev Mode und dem Store

Fehler Nr. 1: „Sofort in den Store, den Rest klären wir später.“
Manchmal will man möglichst schnell „den Markt erobern“ und die App schon im Stadium eines halbfunktionalen Prototyps in den Store stellen. Das führt fast garantiert zu schlechten Bewertungen, schlechter Nutzungsstatistik und zusätzlichen Rückfragen im Review. Gesünder ist es, erst einige Iterationen im Developer Mode zu durchlaufen, Feedback von Kolleginnen, Kollegen und Freunden einzusammeln, den Basis‑UX zu stabilisieren und erst dann in den Store zu gehen.

Fehler Nr. 2: Dev‑ und Production‑Umgebungen vermischen.
Typisches Szenario: Sie konfigurieren den Dev Mode auf dieselbe URL wie Production und wundern sich, warum „ein paar Debug‑Änderungen“ plötzlich echte Nutzer sehen. Trennen Sie Dev‑ und Prod‑URLs so sorgfältig wie bei normalen Webservices. Wenn in der ChatGPT App-Konfiguration ein Production‑URL steht – nutzen Sie ihn nicht für „schnelle Abendexperimente“.

Fehler Nr. 3: Kein klares Verständnis der Zustände.
Wenn Entwickler nicht wissen, in welchem Zustand die App lebt (Draft, Under review, Published, Paused), entstehen seltsame Situationen: Jemand im Team denkt, die App sei bereits im Store; jemand anderes hält sie noch für einen lokalen Prototyp. Beschreiben Sie zumindest im README des Projekts, wo die App steht und was für den nächsten Schritt zu tun ist.

Fehler Nr. 4: Richtlinien und Review bis zum letzten Moment ignorieren.
Manche Teams bauen die App „als wäre es nur eine Website“ und denken erst am Tag vor dem Review an Richtlinien, Berechtigungen und Store‑Anforderungen. Am Ende müssen Erfassung und Speicherung von Daten deutlich umgebaut, Beschreibungen umgeschrieben und Rechte eingeschränkt werden. Besser ist, die Leitplanken von Anfang an mitzudenken und im Dev Mode gleich mit ehrlichen, minimalen Berechtigungen zu experimentieren.

Fehler Nr. 5: Keine separate Strategie für internen und externen Einsatz.
Wenn die App ursprünglich als internes Unternehmenswerkzeug entsteht und später ein öffentliches Produkt werden soll, ist die Zielgruppe leicht zu verwechseln. Intern kann man sich weniger „glänzenden“ UX und komplexere Flows leisten; im öffentlichen Store erwarten Nutzer ein anderes Maß an Komfort. Unklarheit darüber, in welchem Modus Sie sich gerade befinden, führt dazu, dass die öffentliche App wie ein internes Admin‑Tool wirkt, während der interne Pilot stecken bleibt, weil zu früh an den globalen Store gedacht wird.

Fehler Nr. 6: Keine Verbindung zwischen Dev Mode und Observability.
Der Developer Mode eignet sich hervorragend fürs Debugging – dieses Plus sollte man nutzen. Wenn Sie keine Logs anschauen und nicht nachhalten, welche Anfragen ChatGPT in Ihrer Dev‑Umgebung an die App sendet, warten später in Production unangenehme Überraschungen. Nutzen Sie den Dev Mode lieber als Bühne, um das echte Verhalten von Modell und Nutzern zu studieren – nicht nur, um zu prüfen, „dass das Widget kompiliert“.