I built AI that detects when your README drifts from your code — would love your feedback
Hey IH — just launched Driftless after 3 months
of solo building.
The problem: READMEs drift out of sync as code
changes. Nobody's job is to update them.
New contributors suffer.
What I built:
→ Reads actual code (package.json, .env.example)
→ Generates accurate READMEs in 20 seconds
→ Detects drift on every push automatically
→ PR bot alerts team when docs fall out of sync
Free roast tool (no signup): https://driftlessx.dev/#roast
Full product: https://driftlessx.dev
Honest question: is documentation drift a real
pain for you or am I solving a problem that
doesn't hurt enough to pay for?
Would love feedback from this community.
Trending on Indie Hackers
the roast tool as top-of-funnel is the smartest part, free pain-demo before any signup is exactly right. where i'd push back on myself is the 'detects drift on every push' promise, devs already drown in CI noise and a docs bot that cries wolf gets muted within a week. signal quality is everything there. maybe only flag drift on the stuff that breaks onboarding, env vars and setup steps, and ignore prose. not sure where you draw that line but a noisy v1 would kill it
I completely agree. A drift detector that’s technically correct but operationally noisy still fails. I’d rather miss a few low-impact cases than train teams to ignore the alerts. The challenge is finding the boundary where a documentation change becomes a workflow-breaking issue rather than just a content difference.
the "rather miss a few" instinct is right but it kind of just moves the hard part back a step. like what's your actual signal for "this drift matters"? is it which file changed, or are you parsing the readme into discrete claims and checking each one against the code. the second is way more work but it's the only version i'd trust not to cry wolf. curious where you landed on that
Engineer turned founder here. Documentation drift is real—I've felt the pain on my own repos when I come back 2 months later and the README has nothing to do with the actual codebase anymore.
But you're right to question if it hurts ENOUGH to pay for. The solo dev maintaining one repo will tolerate stale docs. The buyer is probably the team lead onboarding new contributors and watching every single one get stuck on the same outdated setup steps. That hour-per-onboard waste IS expensive enough to pay for.
The "Roast My README" free tool is smart—it lets people feel the pain before they decide. I'd watch the conversion from roast → trial closely. That's your real signal.
Just shipped my own thing yesterday. Day 0 solidarity 🙌
Really appreciate this perspective. I think you're right that the buyer may be the team feeling the onboarding and support costs rather than the individual developer dealing with stale docs. Also agree on the Roast → Trial funnel—that's a metric I'm watching closely. Congrats on your launch too 🙌
Really glad the buyer framing was useful. That Roast → Trial metric is the one I'd watch closest — it tells you whether people trust the product enough to try it after being honest about its limits. Good luck with it.
That’s a great way to think about it. A roast shows curiosity, but a trial shows intent. I’ll definitely be watching that funnel closely. Thanks for the perspective and encouragement.
yeah exactly. votes feel good but they don't pay. the people who actually try it are the only signal that matters.watch what they do after the trial too. where they drop off tells you more than where they click.good luck with the launch
here is the links : https://driftlessx.dev
free roast tool : https://driftlessx.dev/#roast
There's an active contradiction above the fold that's harder to recover from than just missing social proof.
Your hero copy says "Join thousands of developers who've stopped writing READMEs by hand." Two sections down, your stat counters say: 0+ READMEs Generated, 0+ GitHub PRs Raised, 0% accuracy. The copy asserts thousands; the numbers say zero. A developer scanning the page doesn't give you the benefit of the doubt — the first thought is "is this made up?" and the second thought is closing the tab.
The fix is simpler than it sounds: remove the three stat counter badges entirely. "Thousands of developers" is vague but at least isn't contradicted without them. If you have real numbers — even 47 repos analyzed in testing — replace the zeros with truth. Right now you're publishing four lines of HTML that do more damage than a blank space would.
I fix this as a flat sprint — your top 3 issues, PR/diff ready to merge in 48h, $49: https://outboundautonomy.com/fix-sprint
Appreciate the detailed feedback. Just to clarify, the counters aren't actually displaying zero values—they're animated counters that briefly start at 0 before incrementing to their real values. The contradiction you're describing doesn't exist in the final rendered state, so I think this may be a case of interpreting the animation's starting point as the actual data.
That said, thanks for taking the time to review the site. Constructive feedback is always welcome when it's based on the complete experience.