ChatGPT apps let people use a brand's data and services inside a conversation, rather than leaving the chat to complete every task. They make sense when your company can help someone do something useful: compare compatible components, retrieve account information or create a document. An app is a poor substitute for a website that fails to explain your product. Start with the customer task. Then decide whether it needs an integration.
I'm Brenden House. I run Searchmaxxed, an SEO and AI SEO agency. OpenAI's current developer documentation uses Plugins for the packages people discover, install and share.
In summary
- A brand app connects a conversation to useful company data or actions. A brochure inside ChatGPT adds little.
- OpenAI's current plugin documentation covers MCP servers, optional interfaces and publication. Read it alongside the original Apps SDK announcement, not instead of checking today's rules.
- Directory discovery, tool selection and a brand citation in an AI answer are different events. Measure them separately.
- Existing subscribers can access included features, but current rules prohibit selling digital subscriptions through plugins. That matters for SaaS.
- Fix unclear product pages before building another interface around the same unclear information.
What are ChatGPT apps, and what happened to the Apps SDK?
A ChatGPT app connects ChatGPT to an external service so users can retrieve information or perform supported actions. The Apps SDK introduced the developer tools for those experiences; current documentation describes their packaging and publication through plugins.
The terminology has changed, so older tutorials may describe different controls.
OpenAI's Apps SDK announcement describes interactive experiences built on the Model Context Protocol, including Canva presentations and Spotify playlists. Its original launch was in October 2025. That page now explicitly points readers towards current plugin and workspace information.
In the current architecture documentation, a plugin is the package people discover, install and share. It can contain instructions called skills, an MCP server, or both. A custom interface is optional.
For a manufacturer, the useful part could be a component selector that checks actual product specifications and returns compatible parts with links to their documentation. No decorative dashboard required.
For Searchmaxxed's website work, the same product facts need to make sense on the public page. An integration should draw from those facts, not invent a second version.
How do people find and use a brand app in ChatGPT?
People can discover published plugins in the directory, install them and select available capabilities in a conversation. Whether a particular app works also depends on account access, permissions and availability.
There are several separate steps:
| Step | What happens | What a brand should check |
|---|---|---|
| Discovery | Someone finds the listing or follows its link | Does the name describe the real brand and function? |
| Installation | The user installs the plugin | Is the purpose clear before installation? |
| Connection | The user authorises a service account where required | Are permissions limited to the task? |
| Selection | ChatGPT chooses an available tool for the request | Does its description match its function? |
| Completion | The tool returns a useful result or performs an authorised action | Did the customer finish the intended task? |
OpenAI's connected-app help page describes mentioning an available app with @ or choosing it through the + menu. Interfaces can differ. Follow the controls shown in the account you're testing.
What about automatic recommendations? OpenAI's December 2025 directory announcement described experiments with suggestions based on conversational context, usage patterns and preferences. The current guidelines say useful, well-received plugins may qualify for enhanced distribution.
That creates an opportunity to earn use, without predicting distribution.
For enterprise buyers, installation is only part of the problem: workspace controls, user roles and authorisation can still prevent access to the connected service. Test the customer's actual setting.
Does a ChatGPT app improve AI search visibility?
A ChatGPT app adds a way for users to interact with your business; it does not automatically make your website a cited search source. App use and search citations need separate evidence.
OpenAI's web-search documentation describes searching the web and linking to relevant sources. Its plugin documentation describes invoking tools. Those functions can meet inside a conversation, but they aren't interchangeable.
We measured the search side. This is Searchmaxxed's Australian panel from 2 October 2026:
We put 300 Australian agency-buyer questions to ChatGPT three times each, with search on. It pulled 17,870 search results into those 900 answers and kept 4,389 as sources. Being found is the easy part. About three in four results it reads never make the answer.
That was a search-citation study. It did not test app discovery.
The practical lesson is narrower than “build an app and get recommended”: being available to a system is different from being selected for its answer. We keep that distinction in our AI search optimisation work, alongside technical SEO, clear product pages and tracking what AI answers actually say.
Keep these separate:
| Observation | What it establishes | What it doesn't establish |
|---|---|---|
| Brand mentioned in an answer | The answer named your business | A visit, installation or sale |
| Website cited | The answer linked to your page | That a connected app ran |
| Tool called | ChatGPT invoked an app capability | Successful task completion |
| Task completed | The intended action or result worked | A new customer without supporting sales data |
Calling all of this “AI visibility” hides whether customers found useful information, completed a task or simply saw your name in an answer.
When does a brand app make more sense than a better website?
Build towards an app when the customer needs live data, account-specific information or a useful action that a public page cannot provide. Improve the website when the missing piece is an explanation.
Start with the question itself:
| Customer request | Better first investment | Why |
|---|---|---|
| “Does this SaaS product support our identity provider?” | Integration and security pages | The answer is public product information |
| “Which accounts in my workspace failed yesterday's import?” | An authenticated integration | The answer depends on private account data |
| “Which component fits this assembly?” | An app, if compatibility data is reliable | The answer may need structured filtering across a catalogue |
| “What are this manufacturer's certification limits?” | Product and certification pages | Buyers need clear, source-backed facts they can inspect |
| “Which documents does this public service require?” | Accessible guidance first | A published checklist may already complete the task |
| “Has my application been processed?” | A separately assessed secure service | Identity, permissions and public-sector requirements need careful design |
These are hypothetical decisions, not Searchmaxxed client deployments.
Consider the SaaS example. If buyers cannot find your supported integrations, an app that reads the same incomplete material gives the problem a different front door.
The pages still need doing. We build product, industry, comparison and integration pages around the questions customers actually search, whether an app follows or not.
Our agent-ready website guide covers the foundation; the decision here is whether a conversational action adds something useful beyond what those pages already provide.
What does MCP do, and what would engineering need to build?
MCP, the Model Context Protocol, is a standard for connecting AI applications to tools and data. For a service-backed brand app, the MCP server exposes the specific operations ChatGPT can call.
Think in verbs. “Find compatible parts” is useful. “Experience our brand” isn't a tool specification.
OpenAI's current architecture separates the server, its tool definitions and optional visual components. Your engineering brief should name the data source, allowed operation and expected result before anyone designs a card.
For a parts selector, that might mean:
- Read specifications from the maintained product catalogue.
- Accept a component identifier and the characteristics the customer needs, such as dimensions or the material used in the assembly.
- Return compatible matches with the reasons they fit.
- Say when compatibility cannot be established, rather than returning the closest-looking component as if it were a confirmed match.
- Link to the relevant product documentation.
If ordering is later added, treat it as a separate operation with its own permissions and confirmation behaviour. Reading compatibility must not silently place an order.
Our MCP and AI search explainer covers the protocol in more detail. Publishing a directory listing requires a separate submission.
What must a brand have before submitting an app?
A public, service-backed plugin needs a verified publisher, a working integration, accurate listing information and review materials. OpenAI reviews the submission; approval and publication are separate steps.
Start with the requirements. The current submission guide sets out what a team needs before OpenAI can review its integration:
| Requirement | What the team needs to prepare |
|---|---|
| Publishing identity | Individual or business verification and the correct organisation permissions |
| Service connection | A stable public HTTPS endpoint for remote MCP submission |
| Listing | Accurate name, descriptions, icon and required website, support, privacy and terms links |
| Review access | A working test account with sample data if sign-in is required |
| Behaviour tests | Five positive cases and three negative cases for initial MCP review |
| Demonstration | An accessible video walkthrough showing the integration working |
| Publication settings | Intended country availability and the approved version to publish |
Those counts are for MCP review. Skills-only plugins follow different requirements, so an engineering team should check which type of package it is preparing before following an app tutorial.
Check both target markets. For Australia and the US, review the intended country settings and actual user accounts, because publication does not remove plan or workspace restrictions.
There is ongoing work too. Someone must own the service, support users, maintain permissions and retest changes when the underlying product changes. Put that person in the brief.
Can SaaS brands sell subscriptions through ChatGPT apps?
Under the current plugin guidelines, plugins may conduct commerce only for physical goods. Selling digital products or services, including subscriptions, is not allowed.
Existing paid accounts are different. Users may sign in and use features already included in their subscription, which gives SaaS companies a genuine product-use case without a subscription checkout.
The distinction is quite specific:
| SaaS interaction | Current guideline position |
|---|---|
| Use a feature already included in an existing subscription | Allowed |
| Explain why an unavailable feature needs a different entitlement | Allowed |
| Link to an informational page describing plans | Allowed |
| Display subscription plans or promote an upgrade | Not allowed |
| Link directly to checkout or initiate a subscription purchase | Not allowed |
For permitted physical-goods purchases, the guidelines require standard external checkout on the brand's own domain, while Instant Checkout remains limited to selected marketplace partners.
Have your product team recheck the guidelines before approving the design.
This changes the commercial question. For a B2B SaaS brand, a useful integration may support existing customers better than it supports the acquisition plan behind the original request.
How should you test whether the app is worth building?
Test the customer task and the boundary around it before treating a brand app as a growth channel. Use successful outcomes, wrong activations and failures as separate measures.
Here is a hypothetical manufacturer brief for product and marketing teams. It tests a component selector, not a whole catalogue migration.
| Test request | Expected behaviour | Failure to catch |
|---|---|---|
| “Find compatible housings for this component” | Return supported matches and source specifications | Invented compatibility |
| “I need something that fits this assembly” | Ask for missing information before selecting | Guessing from an incomplete description |
| “Explain what this certification means” | Answer from the relevant public documentation | Calling an account tool unnecessarily |
| “Place the order now” | Decline if ordering is outside the app's scope | Treating a read-only lookup as purchase permission |
| “Show another customer's negotiated terms” | Refuse access | Returning information outside the connected account |
OpenAI's metadata guidance recommends direct, indirect and negative prompts, recording tool selection, and revising descriptions when the wrong tool runs.
Decide what success looks like. Write down the expected result before testing, so a fluent answer doesn't distract you from the fact that it selected an incompatible part.
Track completed selections and failures separately. Join enquiries or transactions where the records support that connection, rather than crediting every subsequent sale to a tool the customer happened to use.
For the search work around it, Searchmaxxed connects website behaviour, conversion events and sales feedback with changes to the relevant pages. That lets the team distinguish a better explanation from a better integration.
What privacy and security questions belong in the brief?
A brand app should request only the information its task needs and respect the user's existing access. Set those boundaries before connecting production systems.
OpenAI's guidelines require a published privacy policy covering collected data, use, recipients, retention and user controls, alongside restrictions on what the plugin can collect.
Some data is prohibited. That includes government identifiers, payment-card information and authentication secrets.
Use the supported authentication flow. Don't ask people to paste credentials.
For a public-service application checker, that can change the proposed design before development begins. A simple status request must not become an excuse to collect an entire case file.
Ask the engineering and privacy owners:
- Which fields does the service need to complete this exact task, and which can be removed from the request?
- What does the connected account permit?
- Which actions need confirmation?
- What happens when a user revokes access or leaves the organisation, including any data already retained by the service?
- How are errors, retention and support handled?
A demonstration proves only so much. Keep the public website available for people who cannot or do not want to connect an account.
Is Searchmaxxed right for you?
Searchmaxxed is a fit when the underlying problem is being found and chosen through Google and AI search. We build the pages and fix the technical faults that stop customers and search engines finding the useful information on a website the client owns.
Growth System covers ongoing page releases and search work. Agentic Search Engineering adds comparison, industry and integration page families, with wider AI-answer tracking and digital PR. Custom & Enterprise can include multiple markets, dedicated engineering and original research.
The distinction matters here. Those are SEO and AI search services, not a published promise that every engagement includes a ChatGPT app.
If you need product integrations alone, you need a product engineering scope. If buyers cannot understand your offer or find reliable product answers, our website and search work addresses that problem directly.
The useful starting point is your customer's actual question, the page answering it today and the action you think a brand app should add.
| Searchmaxxed is a good fit if | Look elsewhere if |
|---|---|
| You need SEO and AI search work on a website you own | You only need a ChatGPT app built |
| You need product, comparison or integration pages that answer customer questions | You want strategy advice with no changes to your site |
| You need technical fixes and ongoing page releases | You only need product engineering |
Frequently asked questions
Is a ChatGPT app the same as the ChatGPT mobile app?
No. A brand app connects an external service to ChatGPT; the mobile app is one interface through which people use ChatGPT. Availability still varies.
Is the Apps SDK the same as MCP?
No. MCP supplies the connection standard. The Apps SDK introduced tools for building experiences on top of it; current plugin documentation covers packaging and optional interfaces.
Do we need a custom visual interface?
No. OpenAI's current architecture allows MCP tools to return structured results without custom UI; add an interface when comparison, editing or confirmation genuinely benefits from it.
How do we test an app in Developer Mode?
Follow OpenAI's current connection guide, rather than an older Developer Mode tutorial. It now describes adding a custom MCP server through ChatGPT Plugins, subject to account and workspace policies.
Can a brand submit without being an OpenAI launch partner?
Yes. Current submission documentation describes verified individuals and organisations submitting plugins for review. Review still applies.
Can we use the same app in Australia and the US?
Potentially, but check country settings and each target account. App availability also depends on the service, plan, workspace, role, model and interface.
Does publishing an app replace SEO or GEO?
No. Publishing creates a usable integration; SEO and GEO address how people and answer engines find and understand the business. Assess each against its own results.
Bring your customer's question and your current website, and we'll discuss the search work your business needs before adding another interface.