--- title: "Introducing SupportPages. AI Documentation from Your Codebase." canonical: https://supportpages.io/blog/introducing-supportpages-ai-documentation-from-code updated: 2026-03-03 --- Here's something I've learned over 15 years of building SaaS: documentation is always out of date. It doesn't matter how good your intentions are. You ship a feature on Tuesday. You tell yourself you'll write the help article on Wednesday. By Friday you've shipped two more things and that article still doesn't exist. The feature is live, users are confused, support tickets pile up. I've run teams where we had dedicated documentation writers. It helped, but it didn't solve the problem. The writers weren't in the codebase. They had to chase developers for context. By the time the article was written, the feature had changed. The docs were out of date before they were published. The root cause is simple: documentation is a separate workflow from development. As long as that's true, docs will always lag behind code. ## What if documentation came from the code itself? That's the idea behind SupportPages. When you merge a PR that changes something users will notice, SupportPages reads the code changes, understands what happened, and drafts a help article. Screenshots, steps, explanations. You review it, tweak it if needed, publish it. Done. Your help centre stays current without anyone having to remember to write docs. ## How it works 1. **Connect your repository.** SupportPages integrates with GitHub. You choose which repos to watch. 2. **Ship code.** When you merge a PR, SupportPages analyses the changes. It looks at what files changed, what the PR description says, what the code actually does. 3. **AI generates the article.** If the change is user-facing, SupportPages drafts a help article. Title, explanation, steps, screenshots. It understands your product because it's reading your code. 4. **You review and publish.** One click to review. Edit if you want. One click to publish. The article goes live in your help centre. 5. **Docs stay in sync.** When you update the feature later, SupportPages notices. It flags the article for review or suggests updates. No more orphaned docs describing features that no longer exist. ## Who this is for SupportPages is built for small SaaS teams who ship fast and don't have time to write documentation. If you're a solo founder or a team of 2-5, you know the pain. Every hour spent writing docs is an hour not spent building. But every missing doc is a support ticket waiting to happen. It's a losing trade either way. The ideal user: - Web-based SaaS product - Non-technical end users who need help articles - Ships regularly (weekly or faster) - Current docs are outdated, incomplete, or non-existent - Doesn't have a dedicated technical writer If that sounds like you, SupportPages exists to solve this problem. ## Why now I've been building SaaS since 2009. This problem has existed the whole time. What's changed is that AI can now read code and write coherent documentation from it. A year ago, this wasn't possible. The language models weren't good enough. They couldn't understand a codebase, interpret what a change meant for users, and write a clear explanation. Now they can. The window where documentation is a manual chore is closing. Soon, docs that write themselves will be the default. SupportPages is how you get there now. ## What's next We're launching this summer. Before that, I'm looking for design partners - SaaS founders who want to try it early, give honest feedback, and help shape what this becomes. You'd get a full AI-powered help centre for free. I'd get the feedback I need to build something that actually works. If you're interested, take a look at [supportpages.io](https://supportpages.io) and get in touch. --- ## About the Author **Simon Moxon** has been building SaaS companies since 2009. He's scaled teams to 20+ people, hit £2m ARR, and learned most of the lessons the hard way. Now he's building [SupportPages.io](https://supportpages.io) - help docs that write themselves when you ship code. He writes about what's changed in SaaS and what hasn't. [Twitter](https://twitter.com/simonmoxon) · [LinkedIn](https://www.linkedin.com/in/smoxon/)