OpenAI want to build the best developer product ever - OpenAI's first DevRel, Logan Kilpatrick
OpenAI's first DevRel, Logan Kilpatrick, explains what happens when developer awareness arrives overnight: the challenge moves from finding users to helping them scale, while documentation becomes the product's most important interface.
Logan Kilpatrick joined OpenAI's developer advocacy team on the day ChatGPT reached one million users. The small developer-platform group suddenly had the opposite of the usual DevTools problem: extraordinary demand for a compute-intensive product watched by the whole world.
We talk about platform trade-offs, working inside a continuous launch cycle, why docs outrank every other DevRel activity, listening without losing time for deep work, OpenAI's dependence on developers, and the applications Logan hoped the community would build next.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What changed when ChatGPT created instant developer awareness?
Before ChatGPT, the problem was helping developers understand what they could build with GPT-3.5 and the API. My first day coincided with ChatGPT reaching a million users, so top-of-funnel awareness disappeared as a constraint. A roughly seven-person API team instead had to make the best developer product it could while helping enormous demand scale reliably under real compute limits.
How did you balance platform improvements against new models and APIs?
Core features such as API-key-level usage compete with launches such as new models and the Assistants API. Historically we chose the new capabilities, which was the right decision for that stage even though the platform fell behind. A larger team and a dedicated enterprise-platform group made it possible to improve both rather than continually choosing one.
How did you divide your time in such a fast-moving company?
Plans became obsolete quickly, so I thought in broad buckets: documentation, direct conversations with developers, internal coordination and launch support. There was always more work than the team could finish. As the group grew, we could say yes more often, but the pace and continual launches still required flexible prioritization.
Does intense public attention make it harder to stay scrappy?
Yes. The internal instinct is to exercise agency, ship quickly and accept imperfect first versions, but every small mistake is visible. Developers may understand how APIs are made, yet their businesses also stop when the API fails. I had to become more careful about product, documentation and communication quality without losing the speed I enjoy.
What is the most impactful thing DevRel does at OpenAI?
Documentation, without question. The API reaches developers through the docs; if they cannot find or understand what they need, the quality of the model does not matter. Historically the work was scattered across me and contributors from engineering, product and go-to-market. Building a team whose daily responsibility is documentation should raise that quality substantially.
What did working on the docs teach you?
Technical completeness is not enough. We tended to drop everyone directly into text-heavy details while assuming they were all developers. Different personas need clear landing pages and journeys, supported by diagrams and other formats. The difficulty is that rapidly changing APIs make expensive video or visual content age quickly, so the experience and its maintenance model must evolve together.
Why must OpenAI invest in developer experience even when its models lead?
A company that depends only on having the next best model is fragile in a competitive market. More fundamentally, an API can distribute AI through products to hundreds of millions of people who may never know OpenAI powers the experience. Developers are therefore necessary to the mission, not an optional audience, and the developer product has to become excellent across the whole surface.
How do you decide what developers really want?
Experienced teammates — including people who built developer products at Stripe — are valuable, but direct community feedback is empirical evidence. The hard part is rarely collecting requests; it is ranking them. Public channels and DMs provide high-signal reports, even though staying online competes with the deep work required to fix the docs and support launches.
What did you most want somebody to build with the API?
A multiplayer, multimodal, text-first AI assistant. Billions of people already understand texting, so it offers a familiar interface rather than a new interaction to learn. I saw that as a promising route for bringing AI to many more people.
What should DevTools founders remember while they are still early?
Enjoy the struggle toward success. My first months at OpenAI were memorable because a small team was fighting through problems together. Success brings resources and obvious benefits, but it also creates a very different problem set. The period when a few people are trying to make developers care may turn out to be the most fun part of the journey.