Support Stack E20: Your Product Ships Daily. Why Is Your Help Centre Weeks Behind? with Nivedha Venkatesh (Pageloop)
Engineering ships a change on Monday. Support finds out on Thursday, usually from a confused customer. Or worse, from Fin, which will cheerfully hand out last week’s answer because nobody told it the product changed. Nivedha Venkatesh, Cofounder and CEO at Pageloop, thinks it doesn’t have to work that way, and in this episode she explains docs as code: treating your documentation like a codebase, so docs changes ship alongside the product change instead of weeks after it.
Nivedha screenshares Mintlify’s public docs repo on GitHub to show how it actually works. Categories become folders, articles become files, and a single docs.json defines the structure. Docs updates ride along in the same pull request as the code change, automatic checks catch broken links before anything is published, branch protection means nobody publishes unchecked, and screenshots live in one place, so you update them once and they’re fixed everywhere. She’s not an engineer either, which is rather the point: LLMs have dropped the barrier to entry about as low as it can go.
Then we put the Fin hat on. The Intercom help centre is still the best home for Fin’s content (instant updates, no resync), so we work through what you can borrow today: an AI agent in your release process that uses the Intercom API or MCP to flag which articles a change will break, and why docs as code shines when you’re building your own internal agents. If you own Fin content, run a help centre, or you’re tired of finding out about features after your customers do, this is a practical look at keeping your docs in step with your product.
🔗 Resources mentioned:
Mintlify’s docs repo on GitHub
Google developer documentation style guide
Intercom Help Center API guide
Want daily, practical tips on getting the most out of Fin and Intercom? Subscribe to my daily email list.
Episode transcript
Conor Pendergrast (00:00)
Hello, I’m Conor Pendergrast and welcome to episode twenty of Support Stack. So, Nivedha Venkatesh, it is nice to have you on the podcast. You are co-founder and CEO of Pageloop. How are you doing today?
Nivedha (00:24)
Doing great. Thank you, Conor. I’ve obviously watched so many of your episodes. So it’s honestly super cool to be here. And thank you for having me.
Conor Pendergrast (00:34)
It is my pleasure. So we get to talk about something really cool today, which is it’s actually like it impacts on Fin, and we’ll talk about how Fin reacts to this as well in a couple minutes. But we’re talking about docs as code. So this is, I hadn’t really considered this as a concept until I heard you talking about it. So you are the genesis of this in my mind. I think in a way, if anyone’s familiar with Nathan’s work, Nathan who is another one of our Intercom Community experts, he talks about Fin as code. But Nivedha, what is docs as code? What does that mean? Can you give us a like, what’s the quickest version you can think of?
Nivedha (01:15)
Yeah. So, you know, even before I start, I will preface by saying that I am not a computer science graduate. I’ve never been an engineer. So docs as code is something that I got exposed to, you know, recently, sometime this year. And I think the barriers to entry for a concept like this are, you know, as low as they can be. And so that really helped me also learn about this. And thanks to my tech background. But, okay, coming to what docs as code is, it’s similar to like a file system that’s on your computer. So you have folders, have files inside. But docs as code has been something that technical writers have used for decades now. And when they use something like Git, which is what developers use to maintain their code, to enable collaboration for multiple people to contribute to the same code, make changes without conflicting each other, having version control, which is basically even if I add a comma or remove a full stop, it’s going to be tracked as a change. So which means I can easily roll back to a version that I want to do. So that’s in a nutshell what docs as code is.
Conor Pendergrast (02:30)
Yeah, and so in particular, I guess why do you think it’s becoming more common as a concept now? Like what is it that means that we’re, why are we talking about this today? Why wouldn’t we be talking about this in five years from now, for example, or five years ago?
Nivedha (02:49)
Yeah. I think first thing, like I said, it’s just enabled us to use this because of agents, the capabilities we have. And I think we know that LLMs actually work best with code. And what that really means is they are really good at navigating file systems. With docs as code, basically categories are now like folders and articles inside categories become files. And so when you want to make edits or you want to make changes, it becomes really easy to use LLMs to work with docs as code. Now, why has it become relevant today? It’s because the pace at which we’re all shipping changes to our products is astronomical. I could have never seen this coming. And with that, I think as in support, we’ve always, at least once, we’ve come across a situation where we’re like, the feature shipped, I didn’t even know what this feature was. And docs as code is basically enabled to bridge that gap, because engineers can basically ship documentation along with their code, or even, you know, PMs. And, you know, folks like me who are, you know, not engineers can also contribute to documentation all the same. So I think that’s why it’s become very popular now, especially for fast-moving teams.
Conor Pendergrast (04:14)
Absolutely. And so maybe one thing we should disclaim at this point as well is Pageloop is built around this idea. Pageloop is a product that fits inside this bucket. But you’re not here to just pitch, it’s not just about getting you a bunch of new customers. It’s mostly about saying, like, okay, well, if we’re taking the concepts of docs as code, how would we look at how Fin interacts with content, and how could Fin interact with content if you’re taking a docs as code approach? Both inside Intercom’s help desk and knowledge articles, as well as outside of it. Fin the product and Intercom the help desk, I still have trouble working out which one’s Intercom and which one’s Fin. I’m getting better though. Okay. But one of the things I like to do on Support Stack is show people what we’re talking about. So I’m curious, do you have like, what would stand out as a really good standard of quality docs as code? Like what would you recommend we scan through and look at next?
Nivedha (05:23)
Yeah, I would really love to show you all Mintlify’s documentation that’s maintained on a GitHub repository. And it’s a bit ironic because Mintlify is technically our competitor. But I think they’ve done a fantastic job. And I think on Support Stack, we want to see the best examples, so which is, I’m going to show you all how they maintain docs as code.
Conor Pendergrast (05:47)
Lovely. Well, you pull that up and we will take a peek at it and we can see what it looks like.
Nivedha (05:54)
Can you see my GitHub page now?
Conor Pendergrast (05:56)
I can. I can see a beautiful GitHub file and a list of folders on the left hand side as well. Folders and files.
Nivedha (06:04)
Yep. Fantastic. I’ll start off with showing you basically each of these are like your file systems on your computer. Each of these can, like for example, there is one for their style guide, there’s one for storing images. So anything you want to keep as assets that you would use on your help center or your documentation, you can basically have them as folders here. Now this particular thing that I have opened is called a docs.json. By the way, none of these are things that I would have to create myself. I probably wouldn’t use docs as code if I had to. But these can be generated with Claude or Codex, whichever agent of your choice, very easily. This just represents how your documentation is set up. So basically your tabs, the groups. Now I have to show this a little more easily. So you see how…
Conor Pendergrast (07:09)
See, that’s easier for me to see and read.
Nivedha (07:14)
Yeah, same here. So you see, you know, get started, there’s get started here. Then you see the CLI group. So CLI is a group. So it’s basically a way to describe how you want your documentation to be structured. So you can have multiple tabs, say one for your help center, one for API reference, one for SDKs. And you can have multiple tabs, multiple categories, categories inside categories. So all of that is defined on this docs.json. So this is kind of the index of your documentation, or your docs as code repo. Now, I think the interesting thing, and I love showing this, is you see how it says “update from code changes”. This is, I think, the coolest part about docs as code, because this is actually shipping documentation along with product changes, so everything stays in sync. And you also see how there is “fix broken links”. I think another very, very powerful part of using docs as code, because technical writers for the longest time have built like very, you know, detailed tools that help enforcing rules, say like you can never ship a documentation that has any kind of broken links. And we’ve come across broken links one too many times at this point, you know. I think all of us can agree with that. And you can enforce rules like, you know, check graphs, or make sure there’s no profanity, you know, accidentally. And a whole bunch of these rules can be enforced. You can also set up things like, hey, it has to go through a reviewer, so nobody can just come and publish. So that’s called like branch protection, so you can make sure that only, you know, a few people have the ability to publish documentation. So this is what, you know, a docs as code site would look like. And honestly, when I work with our docs, I am almost never seeing this page. Like never, because most of it can just happen through natural language, you know, me prompting Claude and, you know, doing all that cool stuff. And I think that’s another huge advantage. You know, when you like, if I just have to compare, I know you didn’t ask me, but if I just have to compare it with like traditional knowledge bases, unless they open up their APIs for you to do something, you cannot do it. Thankfully, Intercom with their very latest update, which is a fantastic update to their API, we can now access, say, draft articles or AI content, which was previously not possible. So that is the kind of restriction you will never have with your documentation if it was hosted on your own Git repo, because I basically own all of this. I can ask Claude to do whatever I want here. There are no API restrictions. I can update screenshots, all of that good stuff. So I’ll take a pause here. Tell me if you have any questions.
Conor Pendergrast (10:11)
Yeah, yeah, yeah. So okay, so there’s a lot of different things that we’re talking about there. So we were talking about, for example, hey, your product changes and you need to update the help center. And as you said, traditionally what that means, the best case scenario really for what that means would be that an engineer deploys the change and then tells you that the change has been deployed. And then you have to go and hunt down the relevant articles to change. Now there are ways of speeding that up. Like if you’re using Fin, you can use Operator. You could take a screenshot of what changed, for example. In the future, so we’ve just had the Fin Pioneer event, as of recording that was a week ago. And so what that means is that now they’ll add in a couple more ways of making that easier, like Operator can monitor a Slack channel, but it’s still after the fact. It’s still, this is, in most cases, this is live for customers already. And that’s kind of the best case scenario. Like the gold star is, hey, next week I’m gonna set this live and here are all the changes. But that so rarely happens, for good reasons. Like in a lot of cases, people are under time pressure to make the changes, or they’re just like, it’s ready and they’re waiting on someone to review the pull request. There are pressures there. In most cases, in the worst case scenario, a customer comes to you and is like, or a customer talks to Fin, and Fin gives outdated information because Fin hasn’t been told that the product changed. But what we’re talking about here is, as the engineer is making the actual product change, there are requirements within their pull request, or the merge request or whatever system you’re using, that say, okay, well, you need to be checking for documentation changes as well. And in the same pull request or merge request that has the actual product change, it also has the documentation change. And it’s just done, magically done. And I think like it just is a total shift in how you approach documentation. And like you said, you can have gatekeepers there to say, okay, the styling here is not right or the wording here is not right, but you can also make sure that that’s all well documented and clearly laid out as standards, just like code has standards, as standards for what good writing looks like. And I think it is this really sort of brain-breaking idea in a lot of ways that gets you shifting how you approach documentation fundamentally.
Nivedha (12:46)
I love that. I think you summed it up really, really well. Yeah.
Conor Pendergrast (12:52)
Yeah. And now so, if we’re thinking about it, that’s one job. It’s like keeping documentation fresh as changes happen. But the fix broken links one is also really cool. I discovered this with one of my clients the other day where we found a broken link. And it’s actually like, theoretically that should be easy to check. But you do more or less have to use Intercom’s API to fully confirm at the moment that there are no more broken links in there, that that article is now correctly linked everywhere. Whereas if you have this, then you can just sort of point your AI agent at it. If you have docs as code, your AI agent can check in seconds and make sure that that’s a lot better. Or it could be, I guess, so would you imagine this being a recurring process that just automatically checks for broken links?
Nivedha (13:49)
Great question, because this is actually running automatically. So that’s what, when you think of something that technical writers use a lot, it’s called Vale. So it checks for things like these, and Mintlify and Mintlify-like products will automatically, anytime you push or publish, it will run these checks. It says “review required, all checks have passed”. It does this automatically. So you don’t even actually have to prompt your agent. Sometimes you forget, naturally, so it makes sure all that is done.
Conor Pendergrast (14:23)
Absolutely. I mean, so that’s even better. Like you could just have a recurring job that goes through and checks for dead links, and then you don’t get told when your customer reports the problem. Because that’s the interesting thing about Fin, is like Fin’s not actually following links. So Fin will not really notice when there are dead links. Your customers are going to be the ones reporting that. So having a recurring job that goes through and looks at that is really, really helpful. And then there was another thing, which I think is the bane of every knowledge base, you know, my god. Whoever’s responsible for the knowledge base, the bane of their life is screenshots. And out of date screenshots are such a bane. And it really creates this like barrier to adding visuals to your documentation, which is a real cost at the moment, because thinking about it in a Fin perspective, Fin will provide those screenshots to customers when it makes sense. But it’s so painful to update screenshots in a help center, because who knows where screenshots are. So like, tell me more about how docs as code treats that, and also I guess how Pageloop treats that as well.
Nivedha (15:45)
Yeah. So let’s see, I think first with docs as code, and I think this is really, really cool. Let me go back here. Now, you know how docs as code actually reference an image. So let’s see here, we have images. You know, they’ve stored it here, and there are like different types of images that they’ve used. You know, there’s like a dark mode, light mode and so on. And what basically we do is, when I write the article, or in docs as code, I’m seeing the markdown file. I actually don’t have a screenshot there. I have a path to the screenshot, which means I could reuse the screenshot everywhere, wherever I need. It’s the same path. I come in and update this one screenshot, wherever it’s used, it’s basically updated. So I think this is one of the coolest things about being able to maintain screenshots, and that goes for anything. Even like link redirects are much easier, because everything is just a path. Like even on your computer, you would say, you know, document slash niv slash picture slash image name. That’s the path to that image on my computer. Similar thing happens with docs as code. So it makes it really easy to maintain these screenshots. I think coming to Pageloop, because most of our customers have like very complex UI, this is something that we really wanted to solve for, where our agent, when it detects that a code change has a UI impact, the agent can actually open up your staging account, because you would have given us the login credentials. It’ll automatically navigate to that place, grab new screenshots, figure out where in your documentation the screenshots need to be updated, and it’ll surface it for you to make those changes.
Conor Pendergrast (17:36)
Even better. That’s like, that’s the dream, really. Like, God. What an idea. And so I guess it just means that you always have up-to-date screenshots, which is really nice. And it, like, obviously it’s really nice for customers, but it’s also really nice from a Fin perspective as well, because Fin has the right screenshots. I know we’re not really considering Fin’s feelings here much, but ‘cause Fin’s just… just a tool, just a machine, not a real person. That’s really cool. Okay, so what about like, I guess the other part of this is that it means anyone, if you take this approach, there are a couple of different, so this is a public repository, right? A public GitHub repository. You can do this with a private GitHub repository as well, right? Yeah.
Nivedha (18:30)
Yep, that’s right.
Conor Pendergrast (18:32)
And I guess one of the interesting things about having a public repository that you and I were talking about just before we started recording was, I can also point my AI agent at these files as well. Like I could clone this repo, and then when I’m asking my AI agent, it means it’s not having to go out to the web and crawl a load of pages. It’s just got the files right there and can look at the documentation right there as well. So that probably means a better support… It’s certainly a better product and support experience for me, because I can ask my own AI agent, who’s probably working through, like I use Claude all the time, either Claude Cowork or Claude Code, and I’m working through a project with Claude, and then I’m asking it to go and answer, you know, Intercom questions or Fin questions or other questions. And if it can just grab those from the docs directly in GitHub, that’s a much quicker experience, and one that’s also more likely to find the right answer as well.
Nivedha (19:34)
Yep, that’s absolutely right. And I think the other cool thing about having, if you keep your docs repository publicly available, I as a customer, if I find any inconsistency with Mintlify’s documentation, I could raise a request for them to change something. And their team can internally review things and make those changes if they think it’s right.
Conor Pendergrast (20:00)
Yeah, what a wild idea. Like, because I would often tell someone that part of the help site was out of date, or that something had the wrong answer or something like that. But it’s quite dissatisfying, because often that’s just like, okay, cool, I’ll make a note of that. And then that’s the end of the conversation. Whereas if I’m creating a pull request, then I can see that sit there and look at it and be like, well, I know that they haven’t done it, or I know that they have done it, because I can see that it’s been merged. And it’s a lot more satisfying. Like it feels like I’ve actually had an impact rather than just screaming into the void.
Nivedha (20:36)
That’s true, yeah.
Conor Pendergrast (20:37)
Yeah. So first, like, what would you recommend if someone is, let’s say it’s best case scenario, they’re like a two-day-old startup and they’ve got a product. And they use GitHub and they also use Fin or another AI agent or whatever. Well, like, where do you start here? What’s the prompt that you give Claude Code?
Nivedha (20:58)
No, great point. I think it’s become easier even in the last six months, and I assume it’s going to become even easier. So if I were to do this, I would basically point, create a docs repo first. So Mintlify is my org and, you know, have like, you know, docs, have like, you know, other code repositories where my actual product code sits. I would basically have Claude like look at my code repository, my websites, I would probably give it like sales calls, customer transcripts, point it to some Slack channels if I have customer Slack channels, give it as much information. And I would also give it something like a Google Developer Style Guide, so that there is some kind of style guide that it can consistently follow. You know, Claude is actually pretty cool. Like Claude, Codex, when I say Claude, it’s actually like any agent of your choice.
Conor Pendergrast (21:50)
Yeah, an LLM. Your LLM of choice.
Nivedha (21:50)
They’re all pretty evened out, an LLM. Yeah, yeah, exactly. So you basically get it to give you an output of all the categories, subcategories. So we basically know how to create your information architecture. And if you are a fairly new company, you’re not really having a very complex product already. So it’s actually great for you to start as early as possible, because then your customers are going to need… You cannot be dark on the web without any documentation out there. So that’s where I would start.
Conor Pendergrast (22:25)
Hm. Okay. And then so the style guide sounds good, and then you can just host it in GitHub Pages, I guess, very easily.
Nivedha (22:33)
Yeah, you could do that. Another very easy thing would be to get a Vercel account. A free account also just works. Claude can build the design. It’ll do everything for you. You just have to sit back and watch. So you could pick something like Render or Vercel and just host your docs directly there.
Conor Pendergrast (22:53)
Super. That’s good. Okay. And so that’s getting started. So this is where I put more of my Fin hat on and think, okay, well, what are the concepts that we can use here? I guess there are parts that we could adopt as well if you’re using Fin and you’re using the Intercom help desk. And part of that is things like, you can still use Intercom’s API to read documents. So you could have an AI agent, for example, that sits in your deployment process, that sits in the process where you have engineers making the changes. And as part of that, for every pull request or every merge request, depending on what you’re using, the AI agent goes and checks Intercom’s API and tries to find what’s the documentation that needs to be changed. And it could recommend those changes right there in the pull request, or it could create a new issue for the knowledge manager, or whoever it is, to make those changes. And it can make those changes to the API as well. It isn’t quite as seamless as what we’re seeing here, with the idea of the pull request directly showing it. But you could do it that way. I guess the other thing you could do, which is a bit bodgy, is effectively have a GitHub repo for your docs. And then every time you make a change to your help articles, you’re pulling the updated version into GitHub as well. So you could reflect it that way. It’s not perfect, because it’s not real, you know? But it would be a good way of keeping that track, and keeping your engineers honest about changes and making sure that they’re getting documented very quickly. And then the AI agent maybe monitors that GitHub repository as well and then pushes the changes over to Intercom. So there are ways of thinking about this and not losing those benefits. ‘Cause I do think there are, like, if you’re using Fin, the help center is the best way to have a well-performing Fin AI agent. In your notes, what we agreed is like, yeah, the help center is optimised for Fin. But also the tooling within the help desk is built around having immediate access to all of the help center. So recommendations, for example, work really well because they’re built around the Intercom help desk. And any changes you make in the help desk, Fin gets access to those immediately. There’s no resync required. Whereas external content sources, like if you were hosting it in GitHub and in a public page, you wait seven days for an automatic refresh, or you do a manual refresh and then that takes a couple of minutes to process. So there are still, but like I said, there are still ways of considering, okay, well, what are the benefits here of docs as code, and how could we take advantage of it and embed it in there? There are still ways that we can do it. And I think it’s really interesting and a really, really cool concept to talk through as well.
Nivedha (26:18)
Yeah, it is. And like you said, I think with Fin or Intercom, the MCP is also something that’s available. So you don’t even really need to use the APIs necessarily. You can also use the MCP to do a whole bunch of these things.
Conor Pendergrast (26:33)
Exactly. Yeah, exactly. Okay, cool. So yeah, this has been really interesting. Is there anything else on docs as code that you’d like to talk about? Anything I’ve missed asking you about? And then if not, we’ll get you pitching for Pageloop for a minute. Shill your product.
Nivedha (26:54)
Why not? I think the one thing I do want to call out is, like you said, thinking about Fin, using the Intercom help center is honestly the most optimised way to do it. But there are a lot of use cases where you’re also trying to build internal agents. You probably want to put an agent inside your product, or you want an agent to take certain actions that you’re building by yourself. I think in that case, a docs as code setup would be pretty awesome, and it will be pretty seamless. Yeah, I think I’ve covered everything, yeah.
Conor Pendergrast (27:33)
Super. Okay. So tell us, give us the like two minutes, talk about Pageloop, and then you can tell people how people should find you, and how we can be useful to you.
Nivedha (27:46)
Awesome, thank you. Okay, so Pageloop, we’re built around the concept of having multiple people contribute to your documentation. And what you saw with docs as code, we basically abstracted into a nice WYSIWYG editor. So you never have to see your Git repo, like, you know, at least I sometimes feel a little overwhelmed. And, you know, it basically is fully abstracted into a nice WYSIWYG editor. It’s optimised, or the agent is basically optimised to make decisions for you. Let’s say, you know, a lot of times this happens where you ask multiple people to contribute and you’ll see multiple duplicate articles. And that’s because nobody knows the knowledge base in its entirety. And, you know, having an agent like Pageloop there to be like, hey, this actually doesn’t need a new article, because there is an existing article about this. So we’re just going to go and make updates to that one, or a few other articles that are impacted by this change. And things like, you know, catching broken links that you already saw, and updating screenshots. So I think these are, in a nutshell… And finally, I think the experience of reviewing the changes, because a lot of times, at least when I’ve used Claude to update docs, Claude will just give me a block of text, and I’m like, okay, where did Claude make these changes? I can’t visually see which line was changed, which screenshot was changed. So our WYSIWYG editor basically shows you that, just like, say, on Google Docs, if you’ve left comments, the highlights, or Grammarly highlights. You can think of that as the closest explanation. I think that’s also one of my favourite aspects of our new product. So docs as code comes with Pageloop. And then we also work on top of other help desks, like help centers, like Fin, Zendesk, Pylon, and so on. So you can go to pageloop.ai, and if you actually click on the Book a Demo, it books a meeting with me. So happy to chat if anyone wants to learn more about this.
Conor Pendergrast (29:53)
Yeah. Cool. And I presume we can all find you on LinkedIn as well, Nivedha. Always on LinkedIn.
Nivedha (29:59)
Yeah. Always.
Conor Pendergrast (30:01)
And you do like, I really appreciate what you post, because you do talk about building, but also docs as code, and also knowledge management now and what it’s like in 2026 and onwards into the future. So do go and follow Nivedha on LinkedIn. I’ll leave a link to your LinkedIn profile in the YouTube video description as well, down below. Well, this has been great. Thank you so much for joining. For those looking for me, you can find my wonderful brainy thoughts at customersuccess.cx/daily if you want to get an email every day about making Fin better, primarily the agent, and also thinking through what the future of customer support looks like. That’s what I’m thinking through at the moment as well. And future episodes will be right here. So like and subscribe. Feed my ravenous ego, it will never be satisfied, but you can help. Do your little bit to just give it a little morsel. And you will find, yeah, what else? I don’t know. That’s it. That’s all I got. Thank you so much for joining, Nivedha. I’m clearly getting to lunchtime.
Nivedha (31:10)
Thank you, Conor. This was fantastic. Appreciate it.
Conor Pendergrast (31:13)
And we will… it’s so much fun, I really appreciate your sharing, and goodbye everyone. Goodbye.