Driftless – detects when your README drifts from your codebase
READMEs are accurate when written. Then code changes and nobody updates the docs. I call this documentation drift.
Driftless fixes it in two ways:
- Generates READMEs by reading actual code files (package.json, .env.example, route files) rather than user descriptions. This eliminates hallucinated commands and undocumented env vars.
- After generation, monitors every push with a deterministic diff of analysis snapshots — not AI scoring. When env vars, scripts, dependencies, or API routes change, it flags the drift and optionally comments on PRs.
Technical Decisions Worth Noting:
- Local extraction runs before any AI call. Scripts and env vars come from actual files, AI only writes the description and features.
- Drift scoring is deterministic. I tried letting the model score drift — it hallucinated. Switched to file-level diffing so scores are consistent regardless of which model runs.
- GitHub App uses installation tokens (refreshed before expiry) not personal tokens, so it works across org repos.
signup Drifless today get 7 days free pro trail : https://driftlessx.dev
Free roast tool scores any public README without signup: https://driftlessx.dev/#roast
Happy to discuss the technical approach.
Trending on Indie Hackers
Interesting build.
The thing I'd be careful with is that products like this are often adopted for one reason and justified internally for another.
The technical problem is clear. The commercial problem is figuring out what decision makes someone care enough to install it in the first place.
That's not a call I'd make casually in a thread because it tends to shape the positioning more than the implementation.
Well said. Building the solution is one thing; understanding what makes the problem important enough to act on is another. That's exactly what I'm trying to validate right now. Appreciate the perspective.
Possibly.
The reason I stopped where I did is that the useful part isn't the validation itself.
It's the decision that comes after it.
I wouldn't make that call casually in a thread.
If you'd like the tighter version, drop your email and I'll put it together properly.
Interesting point. I'd actually love to hear the high-level takeaway here if you're willing to share it publicly. I suspect others following the thread would benefit from it too.
Possibly, but that's exactly why I stopped short.
I don't think the useful part is the takeaway itself.
I think it's the decision sitting underneath it.
I wouldn't try to unpack that properly in a thread.
If you'd like the tighter version, drop your email and I'll put it together properly.
Interesting build, Het. The technical approach feels credible because you’re avoiding AI scoring and using deterministic diffs.
My instinct is that the first buyer wedge should not be “any repo with docs drift.” I’d test teams where stale setup docs cause immediate pain: open-source tools with frequent contributors, devtool startups onboarding developers, or agencies handing projects to clients.
The next test I’d run is 20 direct conversations with one of those segments, not more product polish. If useful, I can mock up a first outreach batch: who to contact, what trigger to use, and the first 2 messages..
This is really helpful. I’m increasingly convinced the key question isn’t “who has documentation drift?” but “who feels the pain enough to change behavior because of it?” I’d definitely be interested in your thoughts on outreach and positioning.
Try it out 7 days free trail after sign up : https://driftlessx.dev
free roast tool : https://driftlessx.dev/#roast