On November 15, 2025, we closed $1M in angel funding for Inkeep. We started this company in mid-2024, and this feels like a good moment to write down what we have learned so far, honestly, before the narrative gets polished into something that does not quite reflect what the experience was actually like.
Marcus and I started Inkeep because we kept running into the same problem from different angles. He had spent years building data ingestion pipelines and search infrastructure. I had spent years working on developer-facing products and support workflows. We both kept arriving at the same observation: developer teams with thorough documentation still had support queues full of questions the docs already answered. The gap was not documentation quality. It was retrieval and delivery.
The Problem Was More Specific Than We Thought
Our original hypothesis was fairly broad: developer support is inefficient because answers exist in docs but developers cannot find them. That is true. But what we learned from our first conversations with real teams is that the problem is more specific, and the specificity matters for how you build the solution.
The failure mode is not that developers search and fail to find an answer. It is that developers ask a question in Discord or Slack, where a human has to answer it, and that same answer has already been written somewhere in the documentation. The question came to a human channel first because the developer was already in a human channel. The docs site is a separate tab, a separate mental model. By the time you have typed a question in Discord, opening the docs to search feels like a step backward.
That insight changed how we thought about where to put the agent. We focused on meeting developers in the channels they are already using, not redirecting them to documentation search. That focus shaped the product more than any other single decision in the first year.
What Our Early Customers Taught Us
We brought on our first early-access teams in the spring and summer of 2025. Most were devrel or support leads at developer tools companies with active Discord or Slack communities. A few were infrastructure SaaS teams with Zendesk queues and a small support function.
The thing they asked for most was source citations. Not because they did not trust AI answers in general, but because they needed their developers to trust AI answers specifically. An answer with a citation to a specific documentation page is something a developer can verify and act on. An answer without a citation is something they have to second-guess before they act. That distinction drove a lot of our architecture decisions around how we store and retrieve indexed content.
We also learned early that content freshness is a harder problem than it looks. One team we worked with had a docs site that updated every week as the product shipped. Their agent was giving correct answers about a feature that had changed two weeks earlier because the index had not caught up. The support burden of an AI agent giving stale answers is actually worse than no agent at all, because the developer trusts the answer and then runs into an inconsistency in the product. We built automated sync as a first-class feature partly because of that feedback.
What We Got Wrong in the First Months
We spent too much time on the accuracy of individual answers and not enough time on escalation design in the first few months. Our instinct was to make the agent as knowledgeable as possible so it would not need to escalate. That is the wrong frame. Escalation is a quality mechanism, not a failure mode. An agent that knows its own limits and routes confidently to a human when it reaches them is more useful and more trusted than an agent that always tries to answer.
We also underestimated how much the quality of the source content matters. If a team's documentation is inconsistent or outdated in ways the team has not fixed, the agent will faithfully reflect those inconsistencies. We built Inkeep to be an answer-retrieval system, not a content-remediation system. That is the right call, but it means we now spend real time in onboarding helping teams understand which documentation issues will surface as agent problems and which ones will not.
On the product side: we took too long to build the analytics layer. Teams wanted to know what questions were being asked and which ones the agent could not handle. That is how they improve both the agent and the documentation. We had basic logs but not a proper dashboard until late in the summer. Several early teams asked for it early, and we deprioritized it. That was a mistake.
Why We Raised from Angels
We were not trying to optimize for the largest check. We wanted people who had built developer tools themselves and understood the mechanics of the market we are in. Every investor in this round has personal experience with the problem Inkeep is solving: building products that developers use and maintaining the support surface that comes with that.
The $1M gives us runway to go deeper on the product, specifically on knowledge indexing accuracy and on expanding the integration layer. We have a clear set of integrations that early customers are asking for. The round funds the engineering work to build them properly rather than shipping thin connectors that require ongoing maintenance.
What We Are Building Toward
Priya joined us as Head of Product this year, bringing a background in customer-facing work at developer tools companies. Her view on what support teams actually need day to day has already changed how we think about the analytics and escalation pieces of the product.
The next twelve months are about proving that the deflection quality we see with early-access teams holds as knowledge sources get more complex, as team sizes grow, and as the types of questions being asked broaden. We believe it does. The architecture supports it. But we are building a product company, not writing a research paper. The proof is in what happens when teams run it on their actual support volume, not in how the system looks in controlled conditions.
We are three people working out of San Francisco. We talk to customers often. If you run developer support for a team with an active community or a docs-heavy product, we would like to talk to you.