OpenAI Apps SDK - Building Apps That Live Inside ChatGPT

OpenAI quietly opened ChatGPT app submissions, and the Apps SDK documentation is now live. If you remember the ChatGPT plugin saga from 2023 - the big launch, the quiet sunset, the "we learned a lot" blog post - you might be sceptical. Fair enough. I was too. But having gone through the new SDK documentation, this is a meaningfully different approach, and I think it's worth understanding even if you're primarily building on other platforms.

What's Different This Time Around

The old plugin system was basically "give us an API spec and we'll let ChatGPT call your endpoints." It was clunky, the discovery was terrible, and users had no real reason to use a plugin when they could just ask ChatGPT to write code that called the API directly.

The Apps SDK takes a different angle. You're not just exposing an API - you're building an actual application experience inside ChatGPT. The SDK gives you three things: MCP servers for the backend tooling, a widget runtime for embedding interactive UI inside ChatGPT, and a template system for structuring responses.

That widget runtime is the key differentiator. Your app can render actual interactive elements inside the ChatGPT conversation. Not just text cards or links - proper UI components. This is similar to what Microsoft is doing with MCP Apps in Copilot, and it's clearly the direction the industry is heading. Text-only agent responses are a dead end for anything beyond simple Q&A.

The Development Workflow

OpenAI has structured the development process into four phases, and honestly the documentation is clearer than I expected.

Planning is where you define your use case and map out the tools your app will expose. OpenAI pushes you to think about this carefully, which is good advice regardless of platform. The apps that fail are usually the ones that try to do everything rather than doing one thing well.

Building covers setting up your MCP server and constructing the ChatGPT-side UI. The MCP server handles the backend logic - data fetching, processing, API calls to your systems. The widget runtime handles what users actually see and interact with. If you've built MCP servers before, the server side will feel familiar. The widget runtime is new and specific to ChatGPT's environment.

Deployment is straightforward - get your server running, establish the connection to ChatGPT, and submit for review. OpenAI is running an app review process similar to Apple's App Store, which means there's a quality bar to clear. Whether that quality bar is helpful or annoying probably depends on which side of the review you're on.

Quality assurance is where OpenAI gets prescriptive. They want apps that feel native to ChatGPT's interface, follow specific UX guidelines, and meet security and privacy requirements. They're clearly trying to avoid the plugin-era problem where third-party integrations felt bolted on and inconsistent.

Should You Build for This?

This is the real question, and I think the answer depends on who your users are.

If your target audience already lives in ChatGPT - and a lot of knowledge workers do at this point - then putting your experience inside ChatGPT reduces friction. Same logic as building a Copilot agent for organisations that run M365. Meet users where they already are.

If your audience is using enterprise platforms like Microsoft 365, you're probably better served building Copilot extensions or standalone agent solutions. The ChatGPT app ecosystem is consumer-leaning. Enterprise IT departments aren't managing ChatGPT app deployments the way they manage M365 agent catalogues.

Where it gets interesting is if you're building a product that needs to be accessible across multiple AI platforms. Since both OpenAI's Apps SDK and Microsoft's approach use MCP as the underlying protocol, your backend MCP server can potentially serve both platforms. Build the tooling once, create platform-specific UIs for each host. We haven't fully validated this yet, but the architecture supports it in theory, and that's a meaningful advantage over building proprietary integrations for each platform separately.

The Monetisation Angle

OpenAI mentions monetisation strategies in the SDK documentation, which tells you something about their ambitions for this platform. They're not just building an integration layer - they want an app economy. Whether that materialises is anyone's guess. The history of AI marketplaces and plugin stores is littered with graveyards. But OpenAI has the user base to potentially make this work where others haven't.

For Australian businesses thinking about this, the monetisation conversation is premature. Build for the user experience benefit first. If your tool solves a real problem inside ChatGPT, that has value regardless of whether OpenAI's app marketplace becomes a revenue channel.

Authentication and Security

The SDK covers authentication mechanisms for verifying users, state management for maintaining context across sessions, and security guidelines for data handling. The details here matter if you're in regulated industries. You need to understand exactly what data flows through OpenAI's infrastructure versus staying on your servers. For financial services or healthcare clients, this is the section that'll determine whether the platform is even viable.

The MCP server architecture helps here because the server runs on your infrastructure. ChatGPT sends requests to your server, your server processes them and returns results. Sensitive data doesn't need to sit in OpenAI's systems if you architect it properly. But "if you architect it properly" is doing a lot of work in that sentence - get your security team involved early.

How This Compares to Other Platforms

The AI agent platform landscape is fragmenting fast. Microsoft has Copilot extensibility. OpenAI has the Apps SDK. Anthropic has their own tool-use patterns. Google has Gemini extensions. Each has different strengths and different audiences.

What I find encouraging is the convergence on MCP as a common backend protocol. It means the investment you make in building MCP servers - the data connectors, the business logic, the API integrations - is portable across platforms. The UI layer will always be platform-specific, but the backend work carries over. That's a much better position than the early days of mobile where you genuinely had to rebuild everything for iOS and Android separately.

For our AI agent development work, we're watching all of these platforms and building MCP-first where possible. The protocol maturity is getting to the point where it's a reasonable foundation rather than an experimental bet.

Getting Started

If you want to experiment, the OpenAI Apps SDK documentation walks you through the setup. You'll need an OpenAI developer account, familiarity with MCP server development, and some frontend skills for the widget runtime.

Start small. Pick a specific, narrow use case - a calculator, a data lookup, a simple workflow - and build that end to end before attempting anything ambitious. The apps that'll succeed on this platform are the ones that do one thing really well inside a ChatGPT conversation, not the ones that try to replicate an entire SaaS product in a chat widget.

If you're building across multiple AI platforms and want help figuring out the right architecture, reach out. The cross-platform agent story is still being written, but the early decisions about backend architecture and protocol choice will determine how much rework you're looking at twelve months from now.