ChatGPT App Development
Your customers are asking an assistant instead of opening your portal. Node8 builds the MCP server that lets them get a real answer from your systems, secures it, and takes it through platform review. Most first connectors ship in eight to twelve weeks.
What it means
"Get us into ChatGPT" usually turns out to mean three separable pieces of work, and confusing them is the most common reason these projects stall.
Build the server well and the other two become choices you can make later. Build the listing first and you usually end up rebuilding the server.
The evidence
We catalogued every listing in the public ChatGPT app directory in August 2026. Some of what it shows is directly useful when deciding whether and how to build.
95.6% of the 2,007 companies with a listed app have exactly one, and the most prolific third-party developer has just 29. There is no established head of multi-app publishers to compete with yet, which is not something that stays true for long.
Only 6.7% of listed apps define named skills, the structured capabilities that let an assistant do work rather than answer questions. Most listings are a thin read layer. That is a low bar to clear.
Nonprofit (8), Security (17), Legal (33), and Commerce & Shopping (35). Each maps to a large software market with almost nothing listed against it.
98.7% publish both a privacy policy and terms of service. 99.7% authenticate at install. You do not have to guess what review expects; the listed population already shows you.
Browse the full catalogue by category in the ChatGPT side of the AI Connectors Directory, or read the complete analysis in The State of ChatGPT Apps.
What we build
The connector that exposes your data and actions as tools an assistant can call. We connect existing APIs, databases, and legacy systems, and translate your domain rules into tools that behave predictably when a model chooses to use them.
The most common failure is publishing a thin wrapper over an existing REST API. Assistants work well against a small set of well-named tools that answer real questions, and badly against forty endpoints named after database tables. Deciding that set is the design work.
OAuth or API-key flows, role and subscription-based access, and explicit control over what can be retrieved, by whom, and under what conditions. Reviewers look closely here, and so do your security team.
Where the platform supports it, the interactive component a user sees in the conversation rather than a wall of text: the picker, the card, the confirmation step. This is what separates an app from a data feed.
Preparing the listing, the policies, and the technical documentation, then taking the connector through platform review and responding to whatever comes back.
Onboarding flows, example prompts, and documentation for your users, plus analytics that show which questions people actually ask. That tells you what to build in the next iteration.
Process
We start from the questions your customers or your team already ask, and work backwards to the data needed to answer them. Output is a scoped tool set and an honest read on whether your current APIs can support it.
Implementation against your systems, including the API work needed where the existing surface is not sufficient. You see a working connector in a development client early rather than at the end.
Authentication flows, permission model, rate and scope limits, logging, and the review your security team will want before anything points at production data.
Listing preparation, policy pages, documentation, submission, and responses to platform review feedback. Timing here depends on the platform and the category.
Onboarding, example prompts, usage analytics, and a second pass on the tool set once you can see what people actually ask for.
Eight to twelve weeks is the usual range for a first connector. What moves it is the state of your existing APIs and how much security review your category attracts, not the connector code itself.
One server, several assistants
MCP is an open protocol, and it is the same protocol behind ChatGPT apps, Claude connectors, and Microsoft Copilot’s agent surfaces. That is the strategic argument for building this way: the expensive work, which is the tool design, the permission model, and the integration with your systems, is done once and reused.
Most companies start with ChatGPT because that is where their customers are asking, then distribute to Claude and Copilot once the server is proven. We cover the differences between those surfaces in where an MCP server can be distributed.
Who this is for
Each of these pages lists every app already live in that category, and what companies there typically expose to an assistant.
Why Node8
Node8 is part of the OpenAI Select Partner program and builds on the OpenAI platform daily, alongside MCP work for Claude and Microsoft Copilot. We take connectors end to end: the data and API work, the tool design, the security model, platform review, and the adoption work that decides whether anyone uses the thing after launch.
We also catalogued the entire public ChatGPT directory, which is why the guidance here is grounded in what is actually listed rather than in a point of view. If your use case is a bad fit for an assistant, that is a faster and cheaper thing to learn in a discovery session than in month three.
FAQ
A custom GPT is a configured version of ChatGPT with instructions and files. A ChatGPT app is your own software connected through the Model Context Protocol, so the assistant can query your live systems and take actions against them. A custom GPT knows what you told it; an app can look things up and do things.
Most first connectors take eight to twelve weeks from kickoff to a live listing. The build is rarely the constraint. Selecting the right use case, getting the underlying APIs into shape, passing security review, and platform review are what set the schedule. A narrow read-only connector against a clean existing API can be materially faster.
Cost tracks scope rather than a fixed price list. The variables that matter are how many backend systems the connector reaches, how much work the underlying APIs need before they can support it, whether it writes to production systems or only reads, and how much security and compliance review the category attracts. A single-source read-only connector is a much smaller project than a multi-system one with write actions. We scope this concretely in a discovery session before any build commitment.
Largely, yes, and that is the main reason to build on MCP rather than a platform-specific integration. One well-built server can serve ChatGPT, Claude, Microsoft Copilot, and other MCP clients. What differs per platform is the listing and review process, some presentation capabilities, and the distribution model. Building once and distributing to several surfaces is the normal sequence.
The observable requirements are consistent. In our August 2026 snapshot of the directory, 98.7% of listed apps publish both a privacy policy and terms of service, and 99.7% authenticate at install rather than deferring it. Beyond those, review covers what your tools can actually do, how you handle user data, and whether the app behaves predictably. Treat published policies and a clear permission model as prerequisites, not paperwork.
No. Many connectors are built for internal teams or for a company’s own authenticated customers and never appear in a public directory. Public listing is a distribution choice. The engineering underneath is the same either way, which means you can build first and decide about distribution later.
It is the normal starting condition, not a disqualifier. In most engagements some API or data work is part of the project. What matters is whether the underlying data exists and can be reached at all; the interface in front of it is something we can build.
Node8 is part of the OpenAI Select Partner program and builds on the OpenAI platform daily, alongside MCP work for Claude and Copilot. We are engineers who ship connectors end to end: data and API work, tool design, security, platform review, and the adoption work afterwards. We also catalogued the entire public directory, which is why the guidance on this page is grounded in what is actually listed rather than in speculation.
In a strategy session we work out the best first use case, which data to expose, whether your current APIs can support it, and which assistants to prioritise.