Customer support for DevTools, with Nick Gomez from InKeep
Nick Gomez noticed that roughly 90% of B2B SaaS products have a chat bubble in the corner — and only about one in five developer tools do. That gap is why he started InKeep.
Nick Gomez is the co-founder and CEO of InKeep, an AI support tool built specifically for developer products. His argument is that support for developers looks fundamentally different from traditional B2B SaaS support — it lives across documentation, GitHub issues, and Discord rather than a help center, and developers are actively allergic to the chat-bubble experience that works fine for consumer-facing products.
We get into how InKeep measures whether its AI is actually trustworthy enough to put in front of skeptical developers, what the best developer-tools support teams do differently, and the surprising pattern of customers being won over by the product to the point of wanting to invest in the company.
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.
Why is support for developer products so different from traditional B2B SaaS support?
Developers live in documentation, so even the basic touchpoint is different — in traditional support, people go to a help center or an in-app form, but for developers it's often the docs themselves. A lot of support also happens in community forums, because so many developer products are PLG, bottoms-up companies. Technical support is also just very time-consuming: whenever you're helping a developer troubleshoot, you have to account for their tech stack, you might need logs from them, so it often takes technically-minded support people or actual product and engineering time to help. We started by asking what support should actually look like for a developer product as a company scales, rather than assuming the traditional model applies.
What does InKeep actually do?
We help companies reach users wherever they're already interacting with the product and answer their questions at that exact touchpoint — a search bar embedded in your documentation, a Slack bot, a Discord bot for your community. On top of that, we ingest all the places where knowledge about your product actually exists — GitHub issues, Discord threads, documentation — and index all of it so the AI support bot can answer from it. The classic problem is someone asks something in your docs that was actually answered in Discord, but Discord search is bad and Google can't index it, and that person might not even want to join a Discord in the first place. So the knowledge exists, but the developer can't find it, and they end up creating a support ticket that adds noise to your team. We unify all of that into one experience.
AI support tools have a hallucination problem. How do you actually build trust there?
It's very easy to create a 60-70% solution that can pseudo-answer questions about your product, and a lot of the early solutions in this space fell short because the quality wasn't there — we've talked to teams who explored many options and couldn't get to a level of confidence with any of them. We spend a lot of time constantly experimenting with the latest approaches and models, and we have robust evaluation frameworks so we can verify that any change we make doesn't introduce new hallucinations. Honestly, a big part of it is that our customers have a genuinely high bar for quality, so as soon as they complain about anything, we fix it, and that fix generalizes and helps every other customer too. Working with companies like Pinecone, Anthropic, and Postman, who all care deeply about user experience and quality, has continuously raised our own bar.
What percentage of questions actually get resolved without a human?
It depends heavily on how much knowledge already exists about the product. We give teams a dashboard showing the percentage of questions that were answerable from their documentation, so they can track it as a KPI and use it to improve their docs. On the upper end we've seen up to 90% coverage, typically for more mature companies with a lot of accumulated GitHub issues and Discord content. Earlier-stage companies are more like 30-40%. Even at the lower end, a good chunk of that would otherwise have landed on your support team or engineering team's plate, so it's a big time saver, and it also makes the experience better for the developer, because they don't have to wait for a ticket or worry about getting sold to — they just want to know if a specific scenario is possible with your product.
Aren't developers especially skeptical of AI chatbots specifically?
We hear that a lot, especially from founders and engineering leaders who come from a background of reading all the documentation themselves. But developers are actually some of the heaviest users of tools like Cursor, VS Code with Copilot, and ChatGPT, and it's become an expectation that they can move quickly using conversational LLM tools when they're building. So it makes sense that when they're trying a new product, they'd want that same experience rather than reading through docs manually. We've heard from founders more than once who were personally skeptical of AI and hadn't considered a solution — until a user told them a competitor had a chat bot and asked why they didn't, or said they'd had a good experience with one elsewhere. Once someone asks a question and gets a good answer, they trust it, and they're like, why would I ever read the docs again.
How is this different from just using something like Cursor's own website indexing?
Cursor does have a way to index arbitrary websites, and it's a good quick pass, but it works by grabbing whatever it can as fast as possible rather than something like a full headless-browser crawl, so it doesn't always capture all the content. The bigger difference is that with a tool like ours, the company controls the experience and can add knowledge that isn't on the public web at all — Discord, for instance, isn't publicly indexable, and teams often want to bring in historical support tickets or other private content to power the bot. An AI copilot specifically maintained and overseen by your own team, drawing on those private sources, ends up being better than something that can only scrape the public web.
What do the best developer-tools support teams do differently?
The best ones are really good at closing the loop — when something gets answered on Discord or in a support ticket, does that get reflected back into the documentation or help center? Are they tracking the common things people ask and actually incorporating that into the roadmap, not just answering it once? We help with that by taking all the AI conversations and generating analytics — not just flagging which questions didn't have a good answer, but using AI to summarize exactly what someone was looking for that wasn't answerable. We turn that into weekly and monthly reports that documentation or product teams can use to prioritize their content roadmap or even their product roadmap. Teams that closely monitor that and actually act on it end up with a knowledge base and a product that both keep improving, and fewer support questions over time as a result.
Who typically staffs support at developer-tools companies?
It varies a lot and there's no real prescription. Sometimes DevRel people are the first line of defense for community questions on Discord or a forum. We often see a split where a support team handles proper ticketed support for paying customers, while DevRel or product people handle the community channels. Sometimes the support team owns all of it. Especially at early-stage companies, it's often a genuine group effort — founders want the whole team answering questions because it builds empathy and a sense of responsibility about what people are actually running into. Whatever the title, what matters most is answering as quickly as possible and having genuinely knowledgeable people at whatever layer is handling it.
How do developer-tools companies actually handle support across time zones?
It's genuinely hard — if your team is in-person in San Francisco, answering European or Israeli customers well is difficult given the time difference. Part of the answer is that with an AI support bot, users don't need a human to get help 24/7 — one of our customers, the founder of Windmill, told us it feels like they have an extra team member online around the clock helping users. For the harder escalations, though, I'd generally recommend hiring a full-time person deeply familiar with your product rather than offshoring to a contractor, because technical support requires a genuinely high level of product and engineering knowledge. It also doesn't have to be a dedicated support person — plenty of early-stage companies have an engineer in a different area field some support questions when the rest of the team is offline.
You mentioned some customers have ended up investing in InKeep. How does that happen?
Sometimes a founder or team is genuinely skeptical of AI, their product or support team ends up adopting us anyway, and then they hear great feedback from end users or their own internal team — people saying they'd tried a bunch of AI solutions and none of them were any good until this one actually made a difference. We've had a few cases where the founder tells us they were personally converted, not just their team, and asks if we'd be open to them writing an angel check. We've taken a few of those on, from people we felt were genuinely good to have close to us — it's less about the money and more that they end up being great advisors, people we can go to and ask whether a new feature would be valuable or what messaging would land, because they care about the space and have real product insight.
How does InKeep compare to something like Intercom?
Intercom is quite good at what it does, but what it does doesn't map well onto developer products — an Intercom chat bubble isn't designed to generate a code snippet for you, and a large share of Intercom's customer base is B2C or general consumer-facing, not developer products specifically. One of the original inspirations for InKeep was noticing that something like 90% of traditional B2B SaaS products use a chat bubble like Intercom or Drift, but when I looked at developer products specifically, it was more like one in five. That gap made me ask what value those chat bubbles actually provide, and why that doesn't carry over to developer products. If you poll developers, a lot of them will tell you they're allergic to those chat bubbles — they associate them with sales and lead generation, and with automation that isn't good enough to actually answer their question, so they just want to click through to a human. Everything about how we ingest content and design the end-user experience is built around avoiding exactly that association.