Building Custom GPTs Before OpenAI Did

November 6, 2023. OpenAI held their DevDay keynote and announced GPTs – custom chatbots that anyone could build without code. The AI community treated it as a revelation. Configurable AI assistants with custom instructions and knowledge bases, accessible through a simple builder interface.

We watched the announcement from our office and had exactly one reaction: we were already building this.

The timeline that nobody believes

Here’s what actually happened. In November 2023, we integrated OpenAI’s Assistants API into our dashboard. The integration was rocky – we attempted it, reverted it, then re-integrated it once the API stabilized. By December, we’d migrated our Bulk Chat feature to run on the Assistants API.

Then in January 2024, we shipped the chatbots system. Full CRUD operations for custom GPT-like bots. Users could create a chatbot, give it a name and custom instructions, attach knowledge base files, and share it with their organization. Each chatbot maintained its own thread history. Streaming responses via SSE. The whole thing.

OpenAI’s GPT Store opened on January 10, 2024. Our chatbot system shipped in the same window. We didn’t rush to copy them. We were already on the same trajectory, driven by the same user requests: “I don’t want a general-purpose AI. I want one that knows my business.”

The difference between our implementation and OpenAI’s was structural. Their GPTs ran exclusively on GPT models. Ours worked with any model in our catalog – GPT-4, Claude, Gemini, anything available through OpenRouter. A user could create a customer support chatbot running on Claude 2.1 and a code review bot running on GPT-4, each with their own knowledge base and conversation history.

Why custom chatbots were inevitable

The path to custom chatbots wasn’t mysterious. It was a straight line from user feedback.

By late 2023, we had three types of users. The first group used our chat feature for general-purpose conversations – brainstorming, writing, research. The second group kept pasting the same long system prompts at the start of every conversation because they wanted the AI to behave a specific way. The third group was uploading the same documents over and over because they needed the AI to reference their company’s data.

Groups two and three were doing the same thing manually every session: configuring an AI assistant. They were begging us, without knowing it, to let them save that configuration.

Custom chatbots were the answer. Create it once. Set the instructions. Attach the knowledge base. Use it forever. No re-pasting prompts. No re-uploading files.

Knowledge bases changed the equation

The chatbot builder was useful, but knowledge bases made it powerful.

When a user attached files to a chatbot, we processed them through our RAG pipeline: chunk the documents, generate embeddings, store them in a vector database. When someone asked the chatbot a question, we’d retrieve the most relevant chunks and include them in the context window alongside the conversation history and system prompt.

This turned a general-purpose AI into a domain expert. A law firm could create a chatbot that knew their case files. A marketing team could build one that understood their brand guidelines. An engineering team could make one that referenced their internal documentation.

The technical implementation wasn’t simple. File uploads required parsing PDFs, Word documents, and plain text into consistent chunks. The vector search had to balance relevance with the model’s context window limit. And we had to handle the case where a user’s knowledge base was too large for any single context window – which meant smart retrieval, not just dumping everything in.

But the user experience was simple: upload files, ask questions, get answers grounded in your data. That simplicity was the point.

The GPT Builder: Marina’s idea

In February 2024, we shipped the feature that still makes us smile: the GPT Builder. It was an AI assistant whose entire purpose was creating other AI assistants.

The concept came from Marina, one of our team members. Her observation was that the hardest part of creating a custom chatbot wasn’t the technical setup. It was writing good system prompts. Most users aren’t prompt engineers. They know what they want the bot to do, but they don’t know how to express that as a set of instructions an LLM will follow reliably.

The GPT Builder solved this with a conversational interface. You’d tell it, “I need a chatbot that helps our sales team draft follow-up emails based on meeting notes.” The Builder would ask clarifying questions: What tone should the emails use? Should it include pricing information? How formal should the language be? Then it would generate a complete system prompt, suggest a name, and configure the chatbot.

An AI that creates AIs. It sounds recursive, and it is. But the practical effect was that non-technical users could set up sophisticated custom assistants in five minutes instead of struggling with prompt engineering for an hour.

OpenAI eventually shipped something similar with their GPT configuration flow. We got there by listening to users who told us the setup process was the bottleneck.

The Assistants API bet

Our chatbot system was built on top of OpenAI’s Assistants API, which was a calculated bet. The Assistants API handled thread management, message history, and file retrieval natively. Instead of building all of that from scratch, we leveraged OpenAI’s infrastructure and focused our engineering time on the features that differentiated us: multi-model support, organization sharing, and the GPT Builder.

The bet paid off in the short term. We shipped faster because we didn’t have to build conversation state management. The Assistants API handled the tedious parts – maintaining context across messages, managing thread lifecycle, handling file attachments at the API level.

But it also created coupling. When we wanted to support non-OpenAI models in chatbots, we had to build a parallel conversation management layer because the Assistants API only worked with OpenAI’s models. This led to a period where we maintained two conversation backends: the Assistants API for OpenAI-based chatbots and our own threading system for everything else.

By November 2024, we’d merged everything into a unified thread system that owned its own conversation state. The Assistants API became one option among many, not the foundation. The lesson: third-party APIs are great for speed but dangerous for architecture. Build on them, but don’t let them become your only conversation backend.

Organization-level sharing

The feature that enterprise users cared about most wasn’t the chatbot builder. It was sharing.

When one person on a team created a useful chatbot – say, a compliance checker that knew the company’s regulatory requirements – everyone on the team wanted access. In a consumer product, you’d share a link. In an enterprise context, you need access controls.

We built organization-level chatbot sharing with role-based permissions. An admin could create a chatbot and make it available to their entire organization. Team members could use it without seeing the system prompt or knowledge base contents. The admin could update the knowledge base without disrupting active conversations.

This was the moment we realized we weren’t just building a chatbot tool. We were building organizational knowledge infrastructure. A company’s custom chatbots became a repository of institutional knowledge – codified in system prompts and grounded in uploaded documents.

What GPTs taught us about timing

There’s a specific feeling when a major platform announces the thing you’re already building. It’s not quite vindication and it’s not quite fear. It’s something in between. Validation that the problem is real, mixed with anxiety that a company with a thousand times your resources just entered your space.

Here’s what we learned: timing is less important than flexibility. OpenAI’s GPTs were locked to GPT models, locked to OpenAI’s ecosystem, locked to their pricing. Our chatbot system worked with 30+ models, integrated with our knowledge base infrastructure, and could be shared across organizations with RBAC.

When users compared the two, they didn’t choose based on who shipped first. They chose based on what fit their workflow. Teams that needed multi-model access and organizational sharing came to us. Individual users who wanted simple, single-model chatbots used OpenAI’s GPT Store.

The broader lesson is that the AI tooling market is big enough that being second doesn’t matter if you’re different. We weren’t competing with OpenAI on GPTs. We were solving a related problem for a different audience. The custom chatbot concept lives on in Dashboard v2 as specialized agents – each with custom instructions, knowledge bases, and the ability to execute code in sandboxed environments.

We didn’t copy GPTs. We converged on the same idea from different starting points. And that convergence told us we were building in the right direction.