The idea
A service that sits next to your team's wiki and treats every page like food in a fridge: it has an owner, a shelf life, and a date after which somebody has to look at it. It watches for evidence that a page has drifted — the code it links to changed, the API it documents shipped a new major version, nobody has edited it in fourteen months while forty people a week read it — and turns that into a small, specific review task for one named person. Not a nag campaign. One page, one owner, one question: is this still true?
Why build this
Every company past about fifteen people has a wiki where a third of the content is actively wrong, and everyone knows it, and nobody knows which third. The cost is invisible until a new hire follows a runbook that references a service that was decommissioned in March, or a support agent quotes a refund policy that changed two quarters ago.
The usual fix — a quarterly "docs cleanup week" — fails because it asks people to audit hundreds of pages with no signal about which ones matter. The signal already exists, though: page view counts, edit recency, and the git history of whatever the page links to. Nobody joins those three things together. Confluence and Notion both expose enough API surface to do it now, and both have added page-analytics endpoints that make "high traffic, long stale" a computable property rather than a hunch.
Stack sketch
- Backend: Node + TypeScript, Fastify. Jobs on BullMQ over Redis, one scheduled sweep per workspace per night.
- Sources: Notion API (
search+pages.retrieveforlast_edited_time), Confluence Cloud REST v2 including the analyticsviewsendpoint, and Google Docs via the Drive APIrevisionslist. - Code linkage: parse outbound links in page bodies; for any that point at your GitHub org, hit the commits API for that path and record the last commit touching it. A doc whose referenced file changed after the doc's last edit is the highest-quality staleness signal you can get cheaply.
- Storage: Postgres. One
documentstable, onesignalstable, onereviewstable. Staleness score is a materialized view, recomputed nightly. - Frontend: Next.js dashboard — a sortable table of pages by score, plus per-team rollups.
- Delivery: a Slack app that DMs each owner at most one review per week, with Confirm / Needs update / Not mine buttons.
Scope for v1
- One connector only. Pick Notion — the API is friendlier and the auth flow is a single OAuth app.
- Ownership inferred from last editor, overridable in the dashboard.
- Three signals: age since last edit, view count over 90 days, and linked-code drift.
- A single weekly Slack digest per owner, capped at three pages.
- "Confirm still accurate" writes a timestamp back as a page property, so the freshness state lives in the wiki, not only in your app.
Deliberately out: multi-tool federation, LLM-generated rewrites, permissions modeling beyond what the API already enforces, and anything resembling a doc editor.
Where it could go
The obvious next step is suggested edits. Once you know a doc drifted because a specific commit landed, you can pass the diff and the page body to Claude and propose a patch the owner approves in one click — that converts the product from "you have a problem" to "here is the fix," which is a very different price point.
The second path is coverage rather than decay: the same link graph tells you which services, endpoints, and runbooks have no documentation pointing at them at all. Sell that as an onboarding-readiness score. A third path is an API and a CI check, so a pull request that changes a documented file fails soft with "three pages reference this, one is owned by a person who left."
Watch out for
Page-view analytics are the weakest link — Confluence gates them behind plan tiers and Notion doesn't expose them at all on lower plans, so design the score to degrade gracefully to edit-recency plus code drift. And be careful with tone: if the Slack bot feels like a compliance robot, owners will click "Confirm" without reading, and you have built a machine for laundering stale docs into fresh-looking ones.