SupportPages.io

Hey, Simon here. Solo founder of SupportPages. This came from my own product. Every time I shipped a feature, updating the help docs was the job that slipped. Not because it's hard. Because after building, testing and shipping, writing "how to use the thing I just made" is the last job anyone has energy for. So the docs go stale, users get confused, and the gap turns into support tickets. At some point it clicked: the merged PR already contains everything the help article needs to say. The code is the source of truth. Why is a human retyping it into prose? So SupportPages connects to your repo and turns merges into help centre articles. Written guides, annotated screenshots of your actual product, narrated video walkthroughs if you want them. Everything lands as a draft you approve, nothing publishes on its own. You end up with a proper hosted help centre on your own domain that stays current without you thinking about it. I'm early. There's a free plan and I actually want feedback from people who know the stale-docs pain. Tell me what's confusing, what's missing, or what it would take for you to trust generated docs for your own product. I read everything.

I came across SupportPages.io today and was really impressed by its clever concept of automatically updating your help docs, screenshots, and video walkthroughs directly from your codebase every time you ship new code.

Nice idea, solves a real problem most of us just put off. Like that it stays a draft until you approve it.

Draft-until-approve is what makes generated docs safe — auto-publish would be worse than stale pages. The hard part is deciding which PR is a docs event. A CSS-class rename should only refresh screenshots; a settings-path change has to rewrite the article. How do you tell those apart? Also, are the annotated screenshots from a headless browser on a seed account, or inferred from code? That decides whether they match production or a demo state.

Having every merged PR create a draft with refreshed screenshots tackles the exact point where docs usually fall behind. For teams using AI in that pipeline, PZERO at pzero.studio is worth a look.

Good that everything lands as a draft you approve — that is the right default. My question is about what the approval screen shows, because the failure mode here is not stale docs, it is confidently wrong docs that a tired founder waves through. I got burned by a version of this. I write content in Markdown and a generator produces the shipped files. I added legal caveats to a few sensitive items, verified them in the source, moved on. Weeks later I checked the generated output and the caveats were not there: the parser only read text inside code fences, so anything after the closing marker was silently dropped. Source correct, product wrong, no error anywhere. I only caught it because I went looking. Approving a regenerated article has the same shape. If the screen shows me a clean, plausible article, I will skim and approve — plausible prose is exactly what does not trigger scrutiny. If it shows me a diff against the published version, with the sentences the PR actually changed highlighted, I am reviewing a claim instead of proofreading. So: on regeneration, do I see the article, or the delta? And can a UI-only change (renamed button, changed default) be distinguished from a behaviour change in that view? The draft gate is the headline feature. What makes it real is whether the reviewer can see what moved.

The draft-before-publish approach is probably the right choice here. Generated documentation becoming confidently wrong would be worse than slightly outdated docs. One thing I’d be interested in is versioning: if a SaaS keeps an old product version alive for some customers, can SupportPages maintain separate documentation branches, or does the latest merged code always become the single source of truth?

Nice idea, solves a real problem most of us just put off.

"Merge the PR and the help article drafts itself" is a real pain point for us - the docs for MoeMail (docs.moemail.app) routinely lag features by a few weeks because writing them is nobody's favourite job. Two questions before I point it at our repo: a lot of our features are gated by role/plan in code (e.g. permanent mailboxes only for paid tiers). Does the generator pick that up and write "available on plan X", or is that a manual edit each time? And for the auto-screenshots, can it log in with a test account to capture authenticated screens, since almost everything interesting sits behind login?

The idea of generating documentation directly from merged PRs is really practical. Keeping the help articles and screenshots aligned with the actual product should solve one of the biggest problems with maintaining technical documentation.

I really like how simple and easy this product feels to use. It looks genuinely useful and well thought out. Great work!

The auto-publish-on-merge model is the interesting part for me. We run a directory-submission tool where copy drifts across a dozen+ listings and staying accurate is the hard part - so I'm curious how you handle drift that isn't triggered by an obvious PR: e.g. a shared component's copy changes as a side effect of an unrelated merge. Do you diff screenshots/text against the prior version to catch unintentional changes, or is it strictly scoped to the PR's own diff?

SupportPages.io Your product has strong potential, but I found a few key improvements that could make it even better. I'd love to share my feedback and suggestions—please contact me at [email protected].