Developer Mode vs Store

1. Introduction

In previous lectures, we already discussed what a ChatGPT App is, what layers it consists of, and how it differs from old plugins and simple bots on the OpenAI API. Now let’s move on to a second important topic — the lifecycle of such an application.

If you’ve been writing web services for at least a few years, the word “lifecycle” doesn’t scare you. Every product has a basic path: “wrote it locally → rolled out to staging → rolled out to production → sometimes broke everything → fixed it.” In the ChatGPT ecosystem with an App, it’s the same story, but with nuances: there’s a Dev Mode inside ChatGPT itself and a separate entity — the Store.

It’s important to clearly separate two dimensions:

1. Where your code physically lives: a local Next.js server, Vercel, some Kubernetes cluster, and so on. That’s your world — you’re the king there.
2. How ChatGPT sees your App: as a set of metadata, URLs, and permissions that can either be connected in Developer Mode or packaged as a finished product in the Store. That’s the OpenAI world, with its own rules, reviews, and users.

This lecture is about the second dimension. We’ll lean on your familiar environment model (dev / staging / prod) but look at it through ChatGPT’s eyes. Our goal is for you to be able to answer a few questions at any moment. What exact code is my App running right now? Who can see it? How can I experiment safely? And what does it even mean to “update the App” in the Store?

2. Developer Mode: a personal sandbox inside ChatGPT

Let’s start with what’s most pleasant for a developer: a sandbox where you can break everything and almost no one gets hurt.

Developer Mode is a special mode in ChatGPT where you can connect your ChatGPT Apps directly by URL — without review, without publishing the App to the Store, and without showing the App to the entire world. In spirit, it’s like localhost:3000 in a browser, just in the world of ChatGPT.

What it looks like conceptually

The simplest way is to picture it like this:

flowchart TD
    User("ChatGPT UI (Dev Mode)")
    AppConfig["App dev config (URL + metadata)"]
    AppServer["Your app server (Next.js + Apps SDK)"]

    User -->|chat request| ChatGPTCore[GPT]
    ChatGPTCore -->|app needed| AppConfig
    AppConfig --> AppServer
    AppServer -->|UI/tools| ChatGPTCore
    ChatGPTCore --> User

As a developer, in Developer Mode settings you tell ChatGPT: “Here’s my App, here’s its URL, here’s what it’s called and what it can do.” ChatGPT then treats that URL as the source of your application. Until you submit the App to the Store, only you will see it (and possibly other members of your team, if you add them as developers).

We’ll dive into the technical connection details (HTTPS tunnel, Vercel, and other fun bits) later. The key idea here is: Dev Mode is a sort of “dynamic shortcut” to your dev server that ChatGPT knows how to call.

How to enable Developer Mode

To be able to "hook" your local server to the ChatGPT interface, you need to activate the corresponding toggle in the settings.

• Follow the link https://chatgpt.com/#settings/Connectors/Advanced or go to Settings -> Connected apps -> Advanced.
• Developer Mode - ON

As soon as you do this, the Create App button will appear.

How Dev Mode differs from production

The difference is very much like dev vs. production in the regular web, but there are a few specifics.

First, visibility. Your App in Dev Mode is generally not available to ordinary ChatGPT users. Only you and, possibly, members of your organization with the right permissions can see it. You can experiment without worrying that a random person will stumble upon a half-broken UX.

Second, stability and experimentation. In Dev Mode you can change code every two minutes, spin up a local server, kill it, restart the tunnel. ChatGPT will try to call the URL you specified but won’t get upset if you occasionally return a 500 or don’t respond at all — that’s what dev is for.

Third, permissions and policy. Dev Mode makes it easier to try different configurations. But remember that content and basic security policies are not disabled even in dev: ChatGPT won’t let you suddenly turn into a “hacker App for everything.” However, the Store review constraints don’t apply here yet: you don’t need a perfect listing, beautiful logo, etc.

And finally, in Dev Mode it’s usually easier to diagnose problem spots. You can quickly change logic, see what requests ChatGPT sends to your server, and adjust behavior without worrying about “migrating users.”

We’ve looked at Dev Mode as a personal sandbox for applications and briefly peeked toward the Store. Now let’s formalize all this into a clear “state machine” for the App lifecycle.

3. ChatGPT App states: from draft to depublication

Let’s formalize a clear “state machine” for your App. We’ll talk about four main states: Draft / Dev-only, Under review, Published, and Paused/Removed.

Lifecycle state machine

Let’s draw it as a diagram:

stateDiagram-v2
    [*] --> Draft

    Draft: Dev Mode / draft
    Review: Under review (Store)
    Published: In Store, available to users
    Paused: Paused / Removed

    Draft --> Review: Submit for review
    Review --> Draft: Rejected / send back for fixes
    Review --> Published: Approved
    Published --> Paused: Pause / remove
    Paused --> Draft: Resume work in dev mode
    Draft --> Published: Internal rollout without Store (for the organization)

In the Draft state, your App exists only as a dev resource. You can connect it in Developer Mode, try different features, but not expose it in the Store.

When you decide it’s time to show the App to people, you submit it “for review” — that’s the Under review state. There, OpenAI (or an internal review system for your organization) checks policy compliance, stability, basic security, and UX sanity.

If everything is good, the App moves to Published: it appears in the Store or becomes available to your company’s users (for a corporate scenario). From that moment, real users start coming in, and whatever you do with code and configuration needs more careful planning.

If you temporarily don’t want the App to be available, you can move it to Paused/Removed. In Paused, it’s hidden from new users but may continue to work for already started sessions or be disabled entirely — the details depend on the platform and settings.

4. The Store: when your App becomes a product

Developer Mode is your personal garage. The Store is the official dealership. This is where users, ratings, listing rules, and review come into play.

What changes when you go to the Store

First and foremost: your App becomes a “product.” It gets a listing: name, description, icon, categories, and sometimes starter prompts for the dialog. Based on this metadata, the ChatGPT Store will search for and recommend your app to users, and the model will understand in which scenarios the App is relevant.

The second important thing is review and policy. Before your App appears in the Store, it’s checked for security, content, and UX compliance. This means:

• you can’t quietly collect extra personal data;
• you can’t promise what the App doesn’t do;
• you can’t go beyond acceptable content categories.

We’ll talk in detail about policy and sandboxing in later lectures, but it’s already useful to treat the Store as the place where you bring only relatively “well-mannered” versions of your App.

The third thing is responsibility for stability. While you’re playing in Dev Mode, your crashes are your problem. In the Store, your App is expected to have reasonable availability, acceptable latency, and no “red screens of death” in the widget. In later modules we’ll talk about SLOs, metrics, and Store review in this context.

Versions: dev vs. production

A typical question: “If I update the code, what will the user see?” In the world of ChatGPT Apps it helps to think about two branches at once:

• the dev branch, which is connected to Developer Mode and can point to a dev server sitting next to your IDE;
• the production branch, which is associated with the published configuration in the Store and points to a stable URL.

Architecturally, you can even express this with a small TypeScript type in your project:

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 real life, the configuration is stored not by your code but by the ChatGPT platform, but structures like this help you keep in mind that these are two different “images” of the same App.

A ChatGPT App release is closer to an Apple App Store app release than to a website update. Your widgets and MCP tools are cached at app release time each time. And the review can take up to 2 weeks. So none of the “we’ll ship to production and finish testing there.” You must submit for review an already fully tested, stable application.

5. Organizational context: personal account vs. company

We’ve already split the App into dev and production branches and looked at how that shows up in the Store. Another important dimension of the lifecycle is where it lives organizationally.

In the simplest case, you build the App as a private individual in your personal ChatGPT Plus. Then Dev Mode is yours alone, and the Store is also under your account. It’s relatively simple: you made it for yourself, published it, and made the world a bit happier.

But very often, ChatGPT Apps live in a corporate context. Then a few additional roles appear. There are organization admins who decide which Apps are available to employees, which should be blocked, and which can only be used by a pilot group. Your App may be published not for the entire world but only for a specific company — or even for specific departments within it.

In such a scenario, the lifecycle might look like this: first, the App exists only as a dev project within the team; then an “internal production” appears — available, for example, only to the sales department for a pilot. Only then, if everything goes well, you decide to submit the App to the global Store to turn it into an external product.

Architecturally, this matters because you need to design the App so that it works well both as an internal tool and as a public product. Sometimes that means feature flags, “internal-only” modes, and separate authentication settings.

6. Practical scenario: the GiftGenius lifecycle

To keep all of the above from staying abstract, let’s look at a hypothetical App, GiftGenius — a gift selection assistant that will accompany us throughout the course.

Stage 1. Idea and rough prototype in Dev Mode

You decide to build GiftGenius: an App that asks the user who the gift is for, what budget they have, and what the recipient’s interests are, then proposes options using your product catalog.

At the first step you:

1. Spin up a simple Next.js project with a minimal widget.
2. Enable Developer Mode in ChatGPT and add your dev server’s URL there.
3. Run a few test dialogs: ask GPT “Help me pick a gift for a gamer friend under $50” and see how it calls your App, renders the widget, and what the UX looks like.

At this stage, you’re not thinking about the Store, reviews, or pretty icons. Your task is to convince yourself and the team that the idea works at all and that the ChatGPT platform enables the scenario you need.

Stage 2. Hardening the prototype and an internal “alpha”

Once you’re convinced the basic scenario works, the “hardening” stage begins. You:

• bring the logic to a more or less clear structure;
• start thinking about which permissions and data the App actually needs;
• check how the App behaves on errors (for example, when the product catalog doesn’t respond).

Still in Dev Mode, but no longer alone: you add colleagues as developers or testers so they can also connect the App to their ChatGPT. The lifecycle at this stage still revolves around the Draft state: you rapidly update code, try different UX patterns, and discuss feedback within the team.

Stage 3. Preparing for the Store and review

At this point you decide: “Yes, GiftGenius is good enough to show to external users.” Now the focus shifts from code to product packaging:

• you write an honest and clear description of the App;
• you configure permissions: explain which data the App accesses and why;
• you make sure the UX isn’t misleading and that the App doesn’t promise the impossible.

This is the moment of moving from Draft to Under review. You submit the App for review, and it lives in that intermediate state for a while. You may receive comments: clarify the privacy policy, fix wording, narrow permissions. You go back to Draft, refine, and resubmit.

Stage 4. Publication and “real life”

After approval, your GiftGenius lands in the Published state. Now users can discover it in the Store, ChatGPT can suggest it for relevant queries, and you begin collecting real feedback, watching usage, and thinking about scaling.

Now every code change isn’t just “I’ll quickly polish this function.” It’s a mini-release. You need to think about backward compatibility, plan migrations, change the dev version first where possible, test it, and only then update the production configuration.

If necessary, you can temporarily put the App into Paused, for example, if you’ve found a critical vulnerability or your backend can’t handle the load. But the ideal picture is to evolve the Published branch gradually, without forgetting the dev environment for experiments.

7. How to think about environments: dev, staging, production + Dev Mode

Using GiftGenius as an example, we went from an idea in Dev Mode to a published App. Now let’s fit this into a developer’s familiar environment scheme — dev/staging/production — and see how it relates to Dev Mode and the Store.

Most of the time it’s convenient to keep the following matrix in mind:

Developer Mode essentially attaches to your dev or staging infrastructure: you publish a temporary URL that ChatGPT uses for tests. The Store config, meanwhile, points to a mature production URL.

Later, when we talk about deploying to Vercel and tunnels, this matrix will turn into a set of concrete steps. But even now it’s useful to keep a simple idea in mind: always be aware of where the current ChatGPT request is — in your dev sandbox or in the production environment used by real users.

8. A small “piece of code” about the lifecycle

To tie this back to a familiar TypeScript approach, let’s write a simple type that reflects the App lifecycle not at the platform level but at the level of your own tooling. You can put it in the repo to keep the different states top of mind.

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

You’ll never send such an object to ChatGPT, but it helps the team stay aligned. You can even build a simple CLI that shows the state of all your Apps so you don’t confuse what’s a draft and what’s already something living in the Store.

In the following modules, we’ll keep returning to this lifecycle model: when setting up tunnels and Vercel deployment, designing the MCP server and agent scenarios, planning commerce flows, and preparing for Store review. Think of Dev Mode and the Store as two poles of one system: a sandbox for experiments and a storefront for a grown-up product.

9. Common mistakes when working with Dev Mode and the Store

Mistake #1: “Straight to the Store, and we’ll figure it out there.”
Sometimes you want to “grab market share” as fast as possible and publish an App to the Store while it’s still a half-working prototype. This almost guarantees negative user reviews, poor usage stats, and extra questions during review. It’s much healthier to live through a few iterations in Developer Mode first, gather feedback from colleagues and friends, stabilize the basic UX, and only then go to the Store.

Mistake #2: Mixing dev and production environments.
A typical scenario: you point Dev Mode to the same URL as production, then wonder why a “couple of debug changes” were suddenly seen by real users. Separate dev and prod URLs as carefully as you do for regular web services. If the ChatGPT App config has a production URL, don’t use it for “quick evening experiments.”

Mistake #3: No clear understanding of states.
When developers don’t realize which state the App is in (Draft, Under review, Published, Paused), weird situations arise: someone on the team thinks the App is already in the Store, while another still considers it a local prototype. At least describe in the project README where the App is now and what needs to be done to move to the next stage.

Mistake #4: Ignoring policy and review until the last moment.
Some teams build an App “as if it were just a website,” and remember policy, permissions, and Store requirements the day before submission. As a result, it turns out you need to significantly rework data collection and storage, rewrite descriptions, and narrow permissions. It’s better to keep the constraints in mind from the start and use Dev Mode to experiment with honest, minimal permissions.

Mistake #5: No separate strategy for internal and external use.
If an App is initially created as an internal corporate tool and later you want to make it a public product, it’s easy to confuse audiences. Inside a company you can get away with a less “glossy” UX and more complex flows; in the external Store, users expect a different level of convenience. Not understanding which mode you are in now leads to a public App looking like an internal admin tool, and the internal pilot getting stuck because you started thinking about the global Store too early.

Mistake #6: No link between Dev Mode and observability.
Developer Mode is great for debugging — but you need to take advantage of it. If you don’t look at logs and don’t capture exactly what requests ChatGPT sends to your App in dev, production may bring unpleasant surprises. Use Dev Mode as a space to study real behavior of the model and users, not just to check that “the widget compiles.”