Help articles fall behind the product because updating them is a separate job, done later, by someone who has to remember. A page changes, the screenshot still shows the old version, and a customer follows steps that no longer match the screen.
Well Lived handles this by making the help article part of the code change. When the product changes, the article and its screenshot change in the same commit, and they go live on HelpSite in the same deploy as the code. This post walks through how it works, what it has done in its first four weeks, and the one tradeoff to plan for.
What is Well Lived?
Well Lived is a time and energy tracker for your whole life. You talk through your day in your own words, and it shows where the hours went, how they felt, and which patterns are worth acting on. It has a daily log, morning and evening check-ins, a weekly review, goals, and health tracking from wearables like Oura and Fitbit.
That is a lot of pages, and they change often. A product like that needs a help center that keeps up, and its members ask questions in the app, so the answers have to be right.
Its help center lives at help.welllived.io, on HelpSite. Every page in the app has a ? beside its title that opens that page's article, and members can ask HelpSite's AI chatbot, which answers from the same articles.
How does the setup work?
The help articles live in the app's GitHub repository as Markdown files, one per article, in a docs/help folder. From there, four steps keep them current.
- The article changes with the code. Well Lived is built with Claude Code. Its project instructions include a standing rule: any change a member would notice on a page (a new control, a renamed field, a rearranged section) updates that page's article in the same commit. Before committing, Claude looks at what changed and edits the matching Markdown files.
- The screenshot is retaken when the page looks different. Claude runs a capture script against a local copy of the app signed in as a demo account, saves a fresh picture of the page, and commits it with the article.
- The deploy publishes the docs. When the change reaches the main branch, a GitHub Action runs a short sync script. It converts each Markdown file to HTML and sends it to the HelpSite API, which updates the article and publishes it.
- Customers get the new version everywhere. The help center, the in-app ? links, and the AI chatbot all read from the same published articles, so they all change at once.
The sync script is about 260 lines. It never deletes anything on HelpSite, because a deleted and recreated article would get a new URL and break every link to it. New articles are created once as drafts, and their HelpSite IDs are saved in a small map file in the repo, which the app also reads to build its ? links.
What does a typical change look like?
On November 4, the Log page got a phone layout: today's entries now come first, and the entry form now opens from two buttons instead of filling the screen.
That one change updated the page and three help articles. The Log article gained a paragraph explaining the new buttons and the fold-away day timeline. Its old question, "Where's the Log's floating + button?", was replaced with "What does the + button open?", and two related articles had their directions updated to say where the buttons sit on a phone. Nobody had to open a docs ticket or remember to come back to it.
How are the screenshots kept current?
Every page guide shows one screenshot of its page, right after the opening paragraph. The pictures come from Sam Rivera, a fictional demo account seeded with 13 weeks of made-up but consistent data, because the help center is public and should never show a real member's day.
The capture script signs in as Sam, opens each page, and saves the top of it at the same size and theme every time. Articles that walk through several steps get one picture per step, with an orange ring and a short label drawn on the thing to tap. If a page would show anything private or owner-only, the script refuses to save it and the run fails.
Each changed picture is looked at before it is committed. Automation makes retaking screenshots cheap, but a person still decides whether a picture would mislead.
Why keep Markdown in GitHub as well as HelpSite?
It can look like keeping the docs in two places. In practice, each place has a different job.
| GitHub (Markdown) | HelpSite | |
|---|---|---|
| Who uses it | Whoever is changing the product | Members looking for an answer |
| What it's for | Editing, reviewing and history | Reading, search and the AI chatbot |
| When it changes | In the same commit as the code | On deploy, through the API |
Keeping the source next to the code means the docs change with the product, appear in the same diff, and have the same history. A wrong sentence can be traced to the commit that wrote it. HelpSite is where members actually read: a branded help center, search that finds the right article, and AI answers grounded in those articles.
What has it done so far?
The help center went live on October 14, 2026. In its first four weeks:
- 41 articles in 7 categories, from getting started guides to page guides and common questions
- 34 screenshots, all from the demo account
- 85% of article updates shipped in the same change as the code they describe
- 26 releases that updated the help center, all successful
The 85% figure matters most. Most article updates went live with the code they describe, which is the point of the whole setup. For the short version of the results, see the Well Lived case study.
What's the tradeoff?
The repo is the source of truth, so the sync makes every article match its file. If someone edits an article in HelpSite's editor, the next deploy overwrites that edit.
For Well Lived, the rule is simple: edit the Markdown, never the dashboard. A team where support staff fix typos directly in the help center would want one more step, where the sync compares each article with what it last published and stops to ask before overwriting a change it didn't make. Adding that check to the sync script takes a few more lines.
Can you set this up for your own product?
You need three things:
- API access on your HelpSite plan. See pricing for which plans include it.
- A docs folder in your repo with one Markdown file per article, and a short script that sends each one to the HelpSite API.
- A rule for whoever changes the code, whether that's a developer or an AI coding agent, that a visible change updates its article in the same commit.
The screenshots are optional, but they are what keep an article believable. If your app has a demo or seed account, a capture script like this one is worth building early.
If you'd rather not build it yourself, our done-for-you team can set it up for you, as an add-on to a help center build or on its own.
Full disclosure
I'm the CEO of HelpSite, and I also build Well Lived. The numbers above come from Well Lived's own repository and deploy history.
Does HelpSite update articles automatically when my code changes?
Not by itself. Well Lived's setup uses Claude Code to edit the Markdown in the same commit as the code, and a GitHub Action that sends the files to the HelpSite API on deploy. HelpSite publishes what it receives, and its search and AI chatbot use the updated articles right away.
Do I have to keep my help articles in GitHub to use the HelpSite API?
No. You can create and update articles through the API from any system. Keeping Markdown in the repo is one choice that suits software teams, because the docs change in the same commit and review as the code they describe.
What happens to edits made in the HelpSite editor?
In this setup the repository is the source of truth, so the next sync overwrites them. If your team edits in both places, add a check that compares each article with its last published version and stops before overwriting a change it didn't make.