Kinlyze
Know what breaks when a developer leaves - on autopilot
Start new thread

Kinlyze - Know what breaks when a developer leaves - on autopilot

by•
Every team has one engineer who's the only person who understands the payment flow. Nobody measures that risk until they resign. Kinlyze scans git history - never your code, fully offline - and shows knowledge heatmaps, module-level bus factor, and an offboarding simulator: pick a developer, see what breaks. New: the Kinlyze Agent runs scans every weekday and syncs to your dashboard automatically. Pro free for your first month, no card required.

Add a comment

Replies

Best
Maker
📌
Hey Product Hunt! Two months ago I launched Kinlyze here as a waitlist. Today, the thing people kept asking for is live. The problem: every team has that one engineer who's the only person who understands the payment flow, or auth, or that cursed legacy module. Nobody measures that risk until the resignation letter arrives. What Kinlyze does: it analyzes git history - commits, authorship, recency, change size - and shows you knowledge heatmaps, bus factor per module, departure impact per developer, and an offboarding simulator (pick a dev, see what breaks and the recommended handover order). It's 100% local: git metadata only, never your source code, no GitHub OAuth, works air-gapped. What's new since the waitlist launch: 1. Kinlyze Agent - one command (kinlyze agent install --token) and it scans your repos every weekday morning, syncing to your dashboard. Machine was asleep at 9am? It catches up on wake. 2. Cloud reports, multi-repo projects, and combined cross-repo risk views 3. Read-only share links - send your CTO a report without them installing anything Launch offer: Pro is live and your first month is completely free - no card required. I want early adopters using the Agent and telling me what's missing before I even think about billing. Team tier is still on waitlist while I onboard the first teams personally. The CLI and dashboard are free forever - you can scan a repo with zero account in under 5 minutes, or just poke around the live FastAPI demo on the dashboard. Solo founder here, building from Lahore, Pakistan alongside a day job in enterprise integration - I'll be in the comments all day and most of the night What's the scariest bus-factor story from your team?

One thing that would help me a lot as an eng manager: let me toggle which repos or teams Kinlyze watches. Right now it seems to scan everything, and I only really care about the services that have on-call rotation or where bus factor is a worry. Filtering by team or criticality tier would make the daily scan way more actionable instead of noisy.

Maker

 That's really smart feedback. Right now it does scan everything, and you're right that creates noise. Filtering by team or criticality tier would make it way more useful for your workflow instead of just surfacing every single concern equally.

I'm adding this to the roadmap. For now, you can at least pick which repos get analyzed in the config, but toggling by team or marking certain services as higher priority would definitely cut through the signal-to-noise problem you're describing. That's exactly the kind of thing an eng manager needs.

Would love to hear if you hit any other friction once you try it out on your main critical services.

Finally something that answers the question i actually dread asking leadership. The offline-only thing is a big deal, our security team would have blocked anything else. Ran it on a couple repos and the bus factor output was honestly more useful than i expected.

Maker

 That security win matters more than people realize. So many tools get blocked at the gate before anyone even gets to try them. Glad the offline piece solved that for you.

And yeah, the bus factor output being useful is the goal. It's easy to surface false positives, but what people actually need is specific knowledge concentration that actually matters to their operations. If it's helping you identify real risks in those critical services, that's exactly what I built it for.

Thanks for running it and giving honest feedback. That kind of use case is gold for knowing what to build next.