A help article's half-life is how long before it's meaningfully out of date — and for fast-moving software products, it's short. Every release that touches a flow, a label, or a screen erodes the accuracy of the articles describing it. Because re-writing lags shipping, your help center is, at any moment, a mix of current and quietly-wrong content, with no signal to the reader telling them which is which.
The drift is invisible until a user hits it. Nobody audits the whole help center on every release, so articles rot in place. The reader following step four of an article that no longer matches the UI doesn't know the article is stale — they assume they're doing it wrong. That confusion converts into a support ticket or a silent drop-off, and either way the stale article actively cost you something.
Volume makes it worse. The bigger your help center, the more surface area to go stale, and the slower it is to keep current. Teams that pride themselves on "comprehensive documentation" often have the worst drift problem, because comprehensiveness and currency are in direct tension when the product moves weekly.
The fix isn't a documentation sprint. You can't out-write the drift; the product will move again next week. What stays current by construction is a conversation grounded in the product's actual present state — it reflects today's UI because it's reading today's UI, not a snapshot someone captured last quarter. Static docs have a half-life; a live conversation doesn't.
Frequently asked questions
How long do help articles stay accurate?
For fast-moving products, often only until the next release that touches the relevant flow — a short half-life, after which the article quietly misleads readers.
Can you keep documentation current by writing more?
No — you can't out-write a product that changes weekly; the backlog grows faster than it clears. Currency comes from content grounded in the product's present state, not from more snapshots.