Docify
Documentation that updates itself when your code changes
12 followers
Documentation that updates itself when your code changes
12 followers
Docify watches your GitHub, GitLab, or Bitbucket. When code merges, it rewrites the affected section of your existing docs — no duplicates — runs quality checks, and scores every page for AI readiness (can ChatGPT find & cite it?). Free to try.
Launch Team
Viktor.comAn AI coworker that actually does the work
Promoted
the "rewrites the affected section, no duplicates" part is the hard bit most tools in this space get wrong, so curious how you're pulling it off. when it rewrites a section, does it try to match the existing writing style and voice of that doc, or does it just drop in its own templated phrasing regardless of how the rest of the page reads. asking because that's usually where these tools give themselves away, the docs look fine until you notice one paragraph suddenly reads like a different person wrote it
@galdayan Honestly, you caught the exact weak spot. Two things changed after your comment: every doc now follows one fixed writing style — same voice, same words every time — and we check the output after generation instead of just trusting the AI to listen. When a new section goes into your existing doc, we first look at how that doc is written (bullet style, heading style) and make the new part match it. It's not perfect yet on deeper voice matching, but "one paragraph suddenly sounds like a different person" is exactly what we test for now.
@galdayan Forgot one thing — you can also set this yourself. Upload a skill.md file or just write your tone and terminology preferences in the UI once, and it becomes your permanent writing profile. Every future doc and every rewrite follows it automatically.
@praveen_docify that's a solid pair of fixes, checking the output after rather than trusting the generation step is the part that actually matters. the skill.md idea is smart too. question on that - what happens with an existing doc that doesn't have one consistent style to begin with, the kind that's been edited by five different people over two years and already reads inconsistently. does docify pick the dominant style and slowly converge the doc toward it, or does it just match whatever's locally around the section it's touching, which could mean it's consistent with the wrong neighbor
@galdayan Great question — you found the exact trap. Matching only the local neighbor in an inconsistent doc would just make us faithful to whichever of the five authors happens to own that section.
So it works the other way. Before inserting anything, Docify counts the whole document's conventions — list markers, heading capitalization, bullet patterns — and new content follows the majority. If 70% of the doc uses dashes, the insert uses dashes, even when the neighboring section uses stars. The local section only breaks the tie when the document is genuinely split.
The effect over time: every update nudges the doc toward its own prevailing style, one touched section at a time. And we never rewrite sections we weren't asked to touch, so nothing converges without appearing in your review queue first.
There's a hierarchy above that too: if your org has declared a standard (say "sign in", never "log in"), it beats the document majority — even when 70% of the old doc does it the "wrong" way. You set those terms once and every insert follows them.
And honestly, your question pushed us further — for docs too far gone, we shipped a Standardize mode this week: it analyzes the document (consistency scores, current structure vs the recommended blueprint), then rebuilds the whole thing in one voice — every fact kept, duplicates merged — and hands you a single before/after diff with the score change (we've seen 0→100 on structure).
You approve or dismiss; the old version stays restorable.
@praveen_docify the standard-beats-majority hierarchy is the detail that makes this actually usable, not just self-consistent. saw further down that section-level rewrites already land in a review queue with a side-by-side diff before publishing - does Standardize mode route through that same queue, or does a full-doc rebuild skip straight to one approval since it's framed as a single action rather than five separate section edits?
I like that you didn't build another doc generator—you built documentation that stays in sync with the codebase. I'm curious: was keeping docs accurate over time the original problem you set out to solve, or did the AI-readiness angle emerge later? Congrats on the launch! 🚀
@aryan787544 thanks! the staleness problem came first. everywhere I looked, code shipped daily but docs got updated "when someone has time" — which was never. and every tool I tried just created a new file next to the old one, making the mess worse. so section-level sync was the whole idea from day one.
the AI-readiness part came later, while building. I noticed I'd stopped googling tools — I ask ChatGPT first now. and if it can't find or trust your docs, your product simply doesn't exist in that answer. couldn't unsee that, so the score got built in. funny thing is, it's now the feature people ask about most.
One thing I'd love to see is a diff view before the doc rewrite actually goes live, so I can review exactly what changed and approve or tweak it. Even better if it could open a PR against the docs repo instead of pushing directly. Would make me trust the auto-updates a lot more.
@masal1432653 good news — the review flow you described is already in the product, under the Doc sync tab. every AI rewrite lands in a review queue first: you get a side-by-side diff of exactly what changed, plus the reasoning for why that section was touched and which commit triggered it. nothing publishes until you hit approve, and every approval is saved as a version you can roll back.
fair point that it wasn't obvious though — I just shipped a callout inside the app so people actually discover it. the PR-against-your-docs-repo idea isn't built yet, but you've moved it up my roadmap. one question: GitHub PRs specifically, or would GitLab MRs matter to you too?
Poked around the trial and was honestly surprised it caught a stale API reference on a test repo without me flagging it. The AI readiness score is a nice nudge to actually fix pages instead of just letting them rot.
@zgrhyz3 this genuinely made my day — "caught it without me flagging it" is exactly the job I built this for. if the readiness score ever suggests something that feels off, tell me and I'll tune it — feedback like this is how it gets better. thanks for actually kicking the tires 🙏
finally tried docify on a side project and the no-duplicate rewrite was the part that sold me. watched it update just the merged section of my readme instead of appending a whole new block, which is the usual pain with other tools i tried.
@samibeyanghdu thanks, this genuinely made my day. that section-level rewrite was the hardest part to build — took me weeks to get it to stop duplicating headings. curious what size repo you ran it on? and if anything feels rough, ping me here or support@docifydocai.com — solo founder, so fixes ship same-day right now.
Tested it on a small repo and the AI readiness score actually nudged me to fix a few things I had been ignoring. The no-duplicate rewrite feature is the real winner here.
@mustafaaflu this is exactly what I hoped the score would do — not just grade the doc, but point at the specific things worth fixing. if you remember which suggested fixes felt most useful (or useless), I'd honestly love to know — that feedback directly shapes what I build next. thanks for running it on a real repo 🙏