Docsalot: Docs for bots... and not-bots

mike_bifulco-df03e37b-839d-405e-b8aa-1-CFR

Mike Bifulco: [00:00:00] Hi friends, and welcome back to APIs You Won't Hate. My name is Mike Befolco, and I'm sitting down today with a new friend to have a discussion about docs docs of all sorts. If you're an API developer, you've no doubt been exposed to many of them, and I'm really interested to meet and talk with Faizan Khan from Docsalot where we'll be talking quite a bit, I'd imagine, about documentation, but also how the nature of documentation is changing, the way people use docs is changing, and to be perfectly honest with you, the way not people use docs is changing quite a bit as well.

Faizan, thanks so much for joining today. I am super psyched to have you on the show. How are you doing?

Faizan Khan: I'm good. Thanks so much for having me. Excited for this

Mike Bifulco: Yeah, of course. Tell me a little bit about yourself and how you got into the p- the place where you are right now, and I wanna talk about Docslot and, I don't know, the origin story as well.

Faizan Khan: Yeah, for sure. So I'm the CEO of Docsalot as in Sir Docs a Lot. So we create API docs CLIs, SDKs taking in OpenAPI specs. Yeah, a bit about the background. We started as a dev tool product, so it was called SlashML. We went through Alchemist Accelerator, [00:01:00] and we were targeting developers, so trying to get them onboarded.

And as you do, you start bottom up you build a lot of docs, a lot of content, a lot of dev tooling around that, SDKs and stuff like that. And through that, we built an internal tool that was way better than any of the market out there, and SlashML wasn't getting any traction, so we were like, "Okay, let's see if we can sell this."

So we just went around, shopped around and got immediate traction from that. And that's how Docsalot came into being. It's been a year now, almost, on Docsalot itself. And yeah, here we are as it is.

Mike Bifulco: Yeah, we are definitely here. And a- always interested to hear about a pivot and finding traction in particular, but why don't we start here? Tell me a little bit about the elevator pitch for Docslot. So if I've never heard of it before, what does Docslot mean to me?

Faizan Khan: Yeah. So Docs-a-Lot essentially we call it the docs for agents and by agents. So es- essentially what that means is the-- it in-- we ingest everything in your company org, so source code, Slack communication, internal communication could be OpenAPI specs, and then we spit out any [00:02:00] agent-facing or customer-facing content.

So it could be documentation, SDKs, CLIs, MCP server. And it's essentially a dev-focused dev marketing agent that's in your company working with you.

Mike Bifulco: Oh, really interesting. And so that's as contrasted to the typical process or like the maybe old world process of developing documentation. What did it look like before Docsalot and how does that differ from what's here now?

Faizan Khan: Yeah, so before Doxalot, it would be a normal hu- a human basically taking in, reading the product analytics seeing how the people, how users are using the product, and then chatting with a bunch of engineers seeing what features are released, and then just going up there. Could be any other product, could be markdown files, updating the change log, updating the what features were released, and also just adding new pages to onboard more people onto their platform.

Doxalot takes all of that out of the way. And then on top of that, if you have SDKs, MCP servers, you have multiple surfaces that the product manager or the [00:03:00] dev marketing or the dev rel person is maintaining. So we just help with that.

Mike Bifulco: Having worked in DevRel for a long time myself, I'm familiar with the process of maintaining documentation for one SDK in one language is a fairly intensive thing. Usually requires some subject matter expertise. It definitely requires some use of the thing, so testing, like if I'm gonna deploy docs for my SDK, I should be sure that it works.

And then it requires some ongoing maintenance. As the, as bugs are fixed, features are added things of that nature go on within the product organization you need to keep your documentation up to date. And so there's a lot of that I think is interesting and requires nuance. And I think a lot of people might bristle at the idea that their documentation would entirely be written by agents and maintained by agents, but can you tell me what that feels like as the end user of it?

Faizan Khan: So we are not removing the human from the loop. We are just augmenting the human. We are removing the grunt work out of there. So we we bring all of the information onto a dashboard, and then the agent sort of drafts the first version. There is always a human approval required on the final version and the [00:04:00] tweaking and stuff required.

The reason this is helpful is because there is nowadays so much shipping going on with agents small teams are shipping at the rate of 40, 50 engineers. And con- contrast to that, the-- there is still a few-- like the ratio of engineers to human product managers is still five to one on the lower end and could be 10 to one, right?

So the features are being shipped faster, but the customer-facing stuff is still lagging behind. So we augment all of that. People do have internal workflows for that. I'm not saying people can't build that internally. There are some effort, but when people or when teams start doing that, they realize that it's one of those build versus buy kind of thing, right?

They start maintaining their own workflows and then they realize, okay, we need a more reliable sort of system for this to create PRs, to surface relevant customer queries so that we can write relevant pages for them.

Mike Bifulco: That all sounds very familiar to me. And I think having an automated hand in some of that certainly sounds like it would be helpful and could save a fair bit of time. You mentioned earlier [00:05:00] that one of the things that the product does is that you can integrate it with your team's Slack, and you might have mentioned Discord, some other things as well there.

But even-- So I have been using Slack for quite a while too. That's an interesting idea to me too because a lot of the context of what's, what is happening on building out a product happens in DMs, it happens in public channels, it happens in meetings, it happens in planning tools like Jira or Linear or whatever you use.

Tell me about that. Like, how is it listening to Slack, and w- do you get questions from your users about "Oh, should I be nervous that I'm publishing pictures of my cats in Slack and that Doxolot is listening to that?"

Faizan Khan: No. So Slack is like like one of the, the issue that we ran into is Slack is similar to any GitHub integration. Like you go through the IT team or the VP of engineering, and you're really specific about the kind of accesses that you're getting in Slack. So the way it works is it's just a bot that you install, and it only gets invoked if you tag it.

So it's not always on. In Discord it's always on, but in, in Discord's case we have-- you would create a special sort of channel in which it's always on, which is most of the time a customer support [00:06:00] channel, so that when a customer starts a query, the bot responds first, and then there is a human beneath that.

In Slack's case it's just a bot that you tag as you would a human coworker. And then a normal query would be like, "Go look at the previous threads or the previous discussion and just create a page out of this for me to review later." That's it. Like that's as far as we go.

Mike Bifulco: for the folks listening, if you've never had the opportunity to build a Slack bot, it is a little bit baffling and intimidating at first, but you will get that familiar, what would you call it? Like OAuth consent screen where it asks you what you wanna give it access to and all that, and

Faizan Khan: yeah

Mike Bifulco: your stuff can do is brokered by Slack's agreements there too.

Faizan Khan: Yeah. Yeah, it's also like we go through a pretty nitty-gritty detail of onboarding. At this point, like every IT team has evolved the Slack bot. So we are pretty, Like we initially with Slack also started with always on like Discord, but like you mentioned, like you get access to everything, which is not what most teams want

Mike Bifulco: Sure. Yeah, I think that's the first thing that I would be a little nervous about. And [00:07:00] genuinely that's because I publish or pub- publish, I share too many memes with my team and, those don't need to leak into our documentation or whatever it may be.

So it sounds like due to the nature of how the product works, it is largely a tool for communication and obviously generating documentation. Are there any limitations or edges in terms of compatibility with languages? Will it work with Rust and Python and all the things, or is it - specific to certain I guess stacks?

Faizan Khan: No, it pretty much works with everything. The only limitation on is on the SDKs that we generate from OpenAPI specs. We only generate three so far. We can upon request, we can do other things, but like the three are we are con-- is what we are confident about, and you can just get started with it.

Python, TypeScript, and Golang. The rest, it's a question of like we haven't received any customer requests and not enough pull for us to put much effort on that front.

Mike Bifulco: Among the many things that DocsALot ingests, then it sounds like OpenAPI is one of those things, and it'll read your OpenAPI spec and generate documentation, yes, but SDKs as well from it. That's really interesting. That's like a highly competitive marketplace for sure, but definitely [00:08:00] something where if it's embedded in your doc system as well or your process for generating docs and creating docs, sounds like it'd be really interesting.

I was looking at your site for DocsALot, the marketing site, and going through the list of features. There's quite a bit there. It's really interesting. Just to enumerate a few off the top of my head, obviously documentation generation. There is SDKs generation MCPs and then some benchmarking things, like lots of stuff going on here.

I'd love to talk about any of that that you're interested in chatting through.

Faizan Khan: Yeah, for sure. we could talk about how sort of the benchmarking thing or how agents are rather using the docs and how we are thinking about that, because that's an active area of interest among all DevTool people and in, in how to get more agents to use their product rather than humans.

Mike Bifulco: So let's start with that then. What do we, what do you mean agents are reading my documentation? What is that actually under the covers?

Faizan Khan: S-so it's essentially you must have observed it in your workflow or any of your engineers' workflow, like all of us use agents now, like Co-Codex, Claude, Cursor, it could be anything. Like we don't-- When we [00:09:00] try a new tool, all we do is ask Codex to "Okay, sign me up onto that, that tool." So that's how most of the onboarding is happening nowadays, which means that agents are your primary-- If you're a DevTool founder, agents are your primary customer, right?

Like you want to make sure that the agents can onboard itself in as few steps as possible without doing multiple tool calls without ingesting a lot of content. It should just be like read one page and you're there and all of it comes down to the way agents operate.

Like we have a bunch of-- Like we, Because like we think about that a lot, like we observe agentic traffic and want to make sure that our customers get more customers or agents rather. So we-- Like that's one of the key areas that I'm spending a lot of my time on, just analyzing a bunch of traffic that people are getting on their docs.

So one of the things we do, which is a secret, is that we are on Cloudflare, so we route all of the traffic through Cloudflare. So before Cloudflare even had the bot or the [00:10:00] differentiation between Codex and Claude it was just bot. Like you had no idea if it was a crawl- crawler, Google crawler bot or a spam bot or a cursor query or a Codex query.

So which means if you had that disabled, you were not getting any requests. Like your docs were just returning a 403 or a 404. So we let everything in. Like we were like, okay, let's just see if we can do some empirical analysis on that ourselves, and that gives us some-- gave us some really interesting insights, like where to place the index.md or the llms.txt on every page.

Because the way agents read file is they go they go depth first. So they don't browse. They don't look at the index file. They will just find the nearest matching page to the query and just read that page all the way to the end and be like, "Okay, I'm done now. This is it." The onboarding page does not let me onboard Or the onboarding page only has support for X, Y, Z, and therefore we are done. Or in, in worst [00:11:00] cases early on, it would also hallucinate the answer. So it would be like the onboarding page mentioned this, and that, and I'm gonna pattern match it against the other docs that I've read and do-- figure out what it does.

What you want in that case is you want it to recover. You want it to go back to your index file and expo- explore other pages where the answer might exist, right? So that recovery part is really important, and we experimented with a bunch of things like putting the LLMs at the top, putting the LLMs at the bottom, LLMs or TXT in, in every, every page.

In the middle try to stick in. And what we found is if you just put it in the first column and have one simple line that says, "Hey, if you're an agent, we have this llms.txt contains a list of all of the pages in our docs."

Mike Bifulco: Yeah. Wow. You've just said something that's very simple that is a little bit shocking to me in some ways. But okay, let me make sure I understand. So a- agents are coming and browsing my doc site to learn how to use my tool because people are sending it to me from Cursor or Claude or Codex, [00:12:00] and they are using a very algorithm-driven way of seeing what's on my site.

So when they get there, they find the way to go to llms.txt, which is a text file that explains what LLMs have access to on my site, or I think you said index.md, which is a similar idea,

Faizan Khan: both of, yeah

Mike Bifulco: Yeah. And so what you're saying is it gets there and it does the first thing it can find on that first tier is if it says this is onboarding, it thinks that's the onboarding, that's the tendency of it.

And so the escape route is to then give them something that says, "Hey, just so you know, as you're reading through this, there's more stuff here. Go here if you're a bot and get all the stuff." That is... That's really interesting. That's very cool. And obviously not how humans work, right? People don't tend to look at things that way.

Yeah.

Faizan Khan: if you have multiple onboarding paths, like in our docs, we have a CLI onboarding and a web editor onboarding and an MCP onboarding. Like three types of onboardings. If you ask the agent to go onboard itself to Docs a lot, it's if we didn't have the LMS or DXT, it's just gonna be like, "Okay they only have web editor onboarding, so therefore I'm gonna open the browser in Codex [00:13:00] and try to sign up via your Google account."

But in that case, what we want is for for it to use the CLI or the MCP, right? Which is... So yeah, in that case it's really helpful.

Mike Bifulco: Yeah. Oh, that's really interesting. Okay, so pedaling back a little bit then, writing docs for agents and for people, the, the actual, meat and potatoes of the docs of how to do things like, let's say, the "Hello, world" of my SDK. Is there a difference in writing that for people versus writing that for an agent?

Or is it more a matter of how you tell it to get to other things?

Faizan Khan: I think it's subtle differences we don't have that much... so agents want negation on every page. If you don't have a negation like this is what this page does and this is what this page does not do the agent is going to be like, if you remo- if you leave out the do not do part, the agent is gonna be like, "This is the page."

This is it. And there- therefore, because it pattern matches it against text, right? So it's if you say let's say the onboarding. If your onboarding page does not explicitly say that this is web editor only onboarding and we [00:14:00] have other onboarding parts as well, it's gonna be like, "Okay, this is the only onboarding that I could find, and therefore I'm just gonna use this."

Whereas humans will explore. Humans will be like, "Okay, let me see. Let me click a few buttons,"

Mike Bifulco: r-right. Yeah. And to use a weird parallel, humans' context can go beyond that session. I may have been on this page yesterday and remember that there's an MCP or something that I can use here. Oh, man, that-- what a really interesting space to be in. That is at the edge of a lot of things are changing very quickly and how do we all do this well?

And so your you said you found a lot of traction with this product pretty quickly. What did your first customers look like? The people that were actually adopting it, what were-- did they have things in common? Where did they come from surprising places?

Faizan Khan: Yeah, mostly. So like I mentioned, we went through Alchemist Accelerator and the early customers were mostly just us going to them and be like, "Can we create docs for you?" Like manually before we had a product. And that was a clear signal for Paul "Okay, like we don't have time. We have a demo day coming up," and yeah, just do that.

Like we are paying GitBooks and Mandify who [00:15:00] are the sort of the bigger players. Like we're paying them anyways if you can do that half the cost without me touching anything, like just do that. And at that point, we were of course using like coding agents to build all of this ourselves.

And what we initially started with was like, okay, let's just focus on this. Le- let's say if you have a Docusaurus of your docs, can we automate maintaining Docusaurus, like all of the open source, like Astro, Starlight Fuma docs? Like we are platform agnostic. Like we just maintain the docs.

So we were at the GitHub level, if you will. Like we had a Git- GitHub app and we would ingest source code and then just spit out changes to the docs in Markdown or could be HTML file even. Some people had their own custom Next.js file, like in Nextra. And then over time as, as Claude were, was becoming more mature, we realized that, okay, people can build these triggers themselves, maintain these things themselves.

We just started improving the platform, improving the design of our docs, because that's-- when all is said and done, [00:16:00] people still want their docs to look really good, regardless of whether agents are using them or not, because it's it's an expression of who you are as a company or as a product.

Especially if you're in dev tools. Developers tend to be really judgy so if your docs look wipe coded or half done or not aesthetically pleasing they'll be like, "Okay, the product is not that mature." Like they're a bit early

Mike Bifulco: we are our own harshest critics without a

Faizan Khan: Yeah. Yeah. Yeah. So it doesn't matter if agents are the users of docs, like there is still a human at the end of the day making the decision.

So the docs have to look pretty. Like that's one of the key like rule for any docs platform or even if anyone is building it on their own, like your docs have to look pretty. Like I've seen a clear differentiation of in our journey, but also in our customers' journey. When you flip the design of the docs, like you immediately-- people start immediately seeing you as a more mature product.

The product is the same. You just change the design, but it's this [00:17:00] like contrasting difference.

Mike Bifulco: And that in itself is a very human benchmark, right? If you send an agent to the same docs with two flavors of theme or however you wanna look at it, they don't care, They wanna know if it works, and maybe that's more objective certainly, but there's still lots of humans making decisions here and actually, often swiping the credit card.

That's an important angle there.

I would love to talk a little bit about how this is all built. You've mentioned a few bits of tech here, so some Cloudflare stuff and a few different LLM tech. Like what, what's under the covers?

Faizan Khan: Yeah. So it's a-- So the dashboard is built in Next.js platform. We are on Google and Cloudflare in the middle for load balancing and other things. And then for every sort of customer docs, we spin up a separate Cloud Run instance. That helps us make things really isolated and simple.

And in case of if it's an enterprise customer, all we do is just increase the number of load balancing. And if it's a small sort of early pro-tier customer we just spin up a simple smaller instance. It makes it easy for me to price the [00:18:00] product and for customers... and it also makes it just more secure, like everything is sandboxed and isolated.

Like no, no environment leakage is happening. We don't have one box. Yeah, and that was intentional by design when we were building the platform around the same time. I don't want to name them, but like one of the bigger platform had a similar hack happened, and that was one of the hack is someone got access to one box and information leakage did happen from other customers.

So we were like really particular about okay, let's delay the launch, but let's make sure we have separate boxes for everything.

Mike Bifulco: Yeah. I guess probably in your case too, that necessarily means that your, like the bot that has context about my product only can get context about my product 'cause it's cordoned off to that thing and, is listening to my team by whatever ways too, I would imagine.

Faizan Khan: Yeah, that one yeah, that one as well. But the-- it's also more around like the if you have a GitHub app installed in your organization and if someone gets access to that instance the- [00:19:00] they don't have access to other other instances basically, right? So other organizations, right? Hacks can happen, like you can't defend against them, but like it's easier for us to just spin down one instance versus one box that has 1,000 customers, right?

Mike Bifulco: Yeah, that could be problematic,

Faizan Khan: Yeah.

Mike Bifulco: Yeah. Okay. You mentioned a minute ago as well predictable pricing for your customers. Let's talk a little bit about the pricing model. What does it cost to get onboarded? What is in terms of dollars but also time? What does it take for people to get started, and what's it gonna cost them the first time they spin up some docs?

Faizan Khan: Yeah. S-so one caveat is like we are not-- we don't have a free tier. The if people want a free service, they can go to one of the competitors, just search for them, and then they can spin up a good-looking docs. We are... So our lower tier starts at 39, and then it's 99 for the pro tier, which gets you...

And the difference between the two is just if your docs are receiving more traffic and you want more automations you just move to the higher tier. And then we have the enterprise tiers, which has SSO and other things. And it's similar for MCP servers and SDK generation as [00:20:00] well. If you are doing more updates you will go to the upper tier, otherwise on the lower tier it's free.

There is a two weeks free trial, so it's literally free to try it out, everything. And then other than that, we are free core open source. So we have a bunch of open source products using the pro tier. And yeah, so it's commercial and non-commercial, so we give it away for free to open source products.

And in terms of how much it costs us, like the docs platform is really simple to price. Essentially, if you remove all of the AI automation. AI is a bit harder to price. Like you don't know the token pricing and how much how much you are spending versus the versus how much people are using.

So we are still on a predictable pricing. Some-- I see some of the people have gone into credit-based model, which I feel like makes sense for enterprise customers, but for a startup that can be really detrimental. If they, one of their developer comes in and makes 500 changes, do they pay 5,000 now?

Like right. Yeah, it can be unpredictable, especially with startups [00:21:00] when things are moving really fast. The CEO does not have time to add all of the thresholds and automations, right? And our primary like target audience is like startups. Like we are not going after enterprises like that's how we got most of the pull.

And to be honest, we can't serve enterprises at our scale as well. So it's like we love startups, we are at startups level. We still have a...

Mike Bifulco: call to action. If you're build- building an open source product or running a startup and you need docs gen of some sort or SDK gen or MCP gen, like you should be... Your ears should be perking up right now.

Faizan Khan: Yeah. Yeah. Like our thing is like we are serving the one, one poor product manager or the one poor DevRel guy who is getting bombarded by the features that their team is shipping and have no time to just maintain everything. So that's the person that we are targeting.

Mike Bifulco: hugely beneficial if you're that guy. This is the best day of your life, certainly. We were also chatting before I hit record about something that we're, we are happen to be kindred spirits in this world of of building things for people on the web. Tell me about All [00:22:00] Them APIs. What's that?

Faizan Khan: Yeah, so all the APIs started with just our sort of problem of, okay, how are agents using the products, docs, and everything? And then so all the API is essentially a set of benchmarks where what all we do is take public docs of any product, not just ours, could be any product. Like recent, we did a cluster analysis of emails, and then we give it to Claude and Codex, and then we just give it one prompt, and the prompt is the same for all of the benchmarks.

And we're like, "Okay, go onboard yourself onto this product. Create any emails, create any accounts that you want, use any tool that you have access to, but do not stop un- until you're done, and log everything." So we log everything in the process of that onboarding process, and that gave us a really interesting sort of ways of how the Codex is using the tool, but also what docs and products are more prone to agent onboarding versus what are not.

[00:23:00] Clear limitations that I'll just name a few if you have them, and if you're a de- dev tool founder might want to consider thinking around them. One of the ones is so if you have a credit card like trial might want to consider just adding threshold and removing the credit card requirement.

Like that's where a lot of like Firecrawl, I think, was one, and then a few others, which makes sense, like you want to remove spam. But because agents are trying products, they don't have access to credit cards, like you want to give them free stuff to try before, before then. The other one is which is-- which could be a bit harder, but so the the Claude and Codex did have access to Gmail, like my Gmail account or a test account that we created.

But if it requires registration, if there is no social auth, then it just increases the number of steps, and it was prone to fail in one of those steps because the email arrived late, the two-factor auth arrived late, and all of those kinds of things. And then i- in one of the cases [00:24:00] which I won't name, the like if you have three or four products and if you just have one docs for that product again, it, it brings, comes back to the other things that we were discussing.

Make sure you explicitly say that the product that you are looking for is that one not the first page that you found

Mike Bifulco: yeah. Yeah, that I think you called it before n- the show the negatives or show the, show what's not there on that

Faizan Khan: Yeah. Yeah.

Mike Bifulco: yeah. Oh, that's really interesting. As I've spent a lot of my career thinking about information architecture and design of things for people but it really is a very important difference there.

I feel like I'm furiously taking notes here and marking down things mentally to go try out after we get off the phone here. That's really interesting. And so all them APIs is something, it's public, right? People can access this. What's the URL for that?

Faizan Khan: It's allthemapis.com. A-L-L T-H-E-M apis.com.

Mike Bifulco: Very straightforward. I'll make sure that's in the show notes. And so maybe if you're building out an SDK of some sort good to give yours a run through the run-- Yeah, a run through all their APIs to test it out. [00:25:00] Man, that's really fascinating. And so you've certainly taken away a lot from that and it's like a kindred product that's making your features better without a doubt.

I'm curious what's next for you. So what are you excited about that your team is building and what's around the corner?

Faizan Khan: Yeah, so we have lots of exciting features. One of the things that we are thinking on, like I mentioned, is is how can we get more customers or agents for, for our customers that, that's using our platform. So we are thinking of like there is a bunch of things because docs is just one thing, right?

Like there are, there is if you have an MCP server, there is the MCP, but also all them APIs is also a, a sort of a, a path in that direction. Like if you have an API product how can you get more eyeballs on that? So one of the things that we are thinking of is what would a dev marketing person do?

Can we

Mike Bifulco: oh yeah

Faizan Khan: that? How do you get more eyeballs? Some content generation social media automation a change log announcement. How would a human announce that kind [00:26:00] of. So there is some exciting things coming up in that sense, which will give our customers more eyeballs and

Mike Bifulco: that's a great idea. Sure. That's one of those rituals that has to happen with every release and definitely requires human power to do and hours of their lives. And there's lots of good things you can do around branding and brand voice and all that there. That's a super cool idea. I'm really into that.

Okay. So Farzan, be- before I let you go I'm a-- I've got two more questions for you. We we've talked a lot about DocsALot. I don't think I've said the URL, docsalot.dev. There will also be a link in the show notes to that for folks to make sure they check it out. If someone is interested in trying DocsALot or has feedback for you, where's the best place to find you online?

Faizan Khan: So I'm on Twitter, F-A-I-Z-A-N-1-0-double one four. We'll link that. And then on LinkedIn, they can just find me, Faizan Docsalot. I should pop up. Blue Sky as well. Looks like everywhere, but also they can just if you log into any of the websites, you'll see a support or anything, and I should pop up on the website at some point.

If I don't, then we are not doing a good [00:27:00] job.

Mike Bifulco: That's perfect. Sounds good. Faizan Khan, th- thank you so much for taking the time to chat with me. It's been really cool learning about Docsalot. I'm excited to see where you'll go, and please feel free to join us back on the pod anytime if you've got additional releases to talk through, or if you have API chat you wanna get into.

Faizan Khan: Yeah, for sure. It's been a pleasure. We'll do another one.