ChatGPT's Apps SDK redefines the distribution calculus for product builders

What changes: living inside the chat, not in your own app

OpenAI's platform documentation organizes the Apps SDK as its own section, alongside API, Agents, and ChatKit, with a clear flow: Plan, Build, Test and publish. This isn't a menu detail. It's an admission that building an "app" for ChatGPT doesn't mean publishing a service that the user accesses through your own domain, it means building a plugin that runs inside the conversation, invoked by the model when it decides that makes sense. Distribution is no longer SEO, an App Store, or paid ads: it's the assistant choosing to call your tool in the middle of a chat.

For whoever decides where to invest a product's growth budget, this is the real shift. Instead of competing for attention outside the platform, the app competes for relevance inside it, and who arbitrates that relevance is OpenAI, not the open market.

The architecture underneath: MCP, skills, and optional UI

The documentation's structure (Core concepts, Plugin architecture, Skills, MCP server) makes explicit that the Apps SDK is built on top of the Model Context Protocol. In practice, the described path is: set up an MCP server, optionally add UI to that server, authenticate users, package the capabilities as "skills," and then package everything as a plugin. This means the app isn't a standalone interface with its own login and onboarding screen: it's a set of tools that the model invokes, with an interface layer treated as optional, not as the main product.

This inversion matters for anyone coming from a traditional app business model. The component that's normally the product (the screen, the visual experience) becomes secondary; the component that's normally internal infrastructure (the definition of tools and data) becomes the central, mandatory part.

The publishing funnel is a curation barrier

The "Test and publish" section of the documentation lists "Connect and test your plugin," "Submit and publish," and, tellingly, a dedicated "Submission error reference." The existence of a reference specifically for submission errors suggests a review process with recurring rejection criteria, not an automatic deploy button. Add to that the "Plugin guidelines," "MCP server review requirements," and "UI guidelines" documents: there are content rules, MCP server security rules, and visual standard rules before any plugin reaches the end user.

The most direct parallel is with app store review, but with a structural difference: here, curation doesn't just filter the binary, it filters how and whether the model can invoke the plugin in a conversation. There's even an "Optimize Metadata" guide, the equivalent of ASO (App Store Optimization) inside the chat: how to describe the tool so the model chooses it more often. This creates a new growth discipline, one that isn't marketing to humans, it's marketing to the language model itself.

Checkout inside the chat: monetization with a pre-defined format

The most relevant point for anyone thinking about revenue lies in the "Conversion specs": Restaurant reservation spec, Get Quote spec, and Product checkout spec, plus a dedicated "Checkout API reference." This indicates that OpenAI didn't leave monetization open for each developer to solve however they wanted: it standardized transactional flows into specific categories (reservation, quote, purchase) and offers a checkout API that the plugin must follow to close a sale inside the conversation.

For the founder, this is the difference between "I decide how I charge" and "I fit into the billing format the platform has already defined." A business whose conversion model doesn't look like a reservation, quote, or product checkout simply doesn't have, today, a ready-made conversion spec to follow, which is a signal of priority: OpenAI is optimizing first for commerce and transactional services, not for any type of revenue model.

Ads: the other revenue engine competing for the same screen

The same documentation lists, alongside the Apps SDK, an Ads section with Advertiser API, Campaign Management, Bidding and Budgets, Targeting, and Conversion Tracking. This matters because it shows that the attention inventory inside ChatGPT won't only be contested among plugins competing for organic relevance: there's also a paid channel, structured as a campaign API just like any media platform. Whoever builds an app within the Apps SDK is, in practice, competing for the same attention space that paying advertisers will also fight over.

The client company's admin is the second gatekeeper

There's still another layer of curation that a founder selling to businesses can't ignore: the ChatGPT Work administration documentation includes "Plugin controls," "Plugin management," and "Skill controls" as governance features for workspace administrators. This means that, even after passing OpenAI's review, a plugin still depends on each client company's IT administrator approving its use. Distribution inside corporate ChatGPT isn't an open market, it's a market with two levels of approval: OpenAI's and the enterprise buyer's.

The counterpoint: the cost of giving up your own channel

The easiest reading is to treat this as free access to a gigantic user base with no acquisition cost. The counter-argument that needs to be faced before any bet is the opposite: by depending on the Apps SDK, the founder loses the direct relationship with the customer. It isn't the app that decides the onboarding journey, it's the model. It isn't the app that sets the pricing and billing rules, it's the platform's Checkout API. It isn't the app that controls how it will be discovered, it's metadata optimization within OpenAI's rules. A business that builds its entire distribution on top of this layer is exposed to any change in curation policy, revenue share, or conversion spec priority made unilaterally by the platform, the same risk that any app store developer already knows, but applied to a channel that's even newer and less predictable.

What this changes for decision-makers

The practical implication for whoever allocates product and growth budget is to treat the Apps SDK as an additional distribution channel with terms defined by OpenAI, not as a substitute for your own channel. It makes sense to test the Apps SDK when the business model already fits the existing conversion specs (reservation, quote, product checkout) and when the metric that matters is reach inside AI conversations, not full margin on every transaction. It doesn't make sense to migrate your entire acquisition strategy into ChatGPT while the review process, the rejection criteria documented in the submission error reference, and the metadata rules are still taking shape: it's a channel to diversify, test, and learn from, not one to bet the entire distribution of the business on.