Launching today
Your best work is probably under an NDA, so nobody can see it. Nobody trusts CVs anymore, they are so fakeable. Redential reads your git history on your own machine and turns it into a profile of what you actually built. Never your code, and you see exactly what gets shared before it does. Then you defend it live, answering questions about your own work. The result: a credential recruiters can trust more than a CV. The CLI is free and open source.
Hey Product Hunt 👋
I'm Juan, founder of Redential.
Here's the problem that made me build this: Nowadays a CV can be faked and polished, a github can be cloned, none of it shows anyone that you really know how to do the job.
So the question became: what can't be faked? The answer: work you actually did and the memory of doing it.
Here's how Redential works:
🔍 Scan your work, locally (Open Source CLI).
Run 'npx redential scan' on any repo, no account needed. It reads your git history on your own machine and detects what you actually built with: not just "Stripe is installed", but real patterns, like a webhook flow with signature checks and duplicate-payment protection, connected.
You can also connect the github app to your repos if you don't choose the CLI path.
🔒 Your code never leaves your machine
Only a small summary does: languages, activity, skills, and you see the exact data before anything uploads. This isn't a promise: the privacy rules are tests inside the open source repo, and you can run them yourself.
🪪 Get a public profile
Your work becomes a credential you can share with recruiters: what you built, with what, for how long. Even the work nobody was allowed to see.
🎤 Defend it live
This is the part that's hard to fake. You answer questions about your own work, in real time, generated from your own history. If you did the work, you remember it. If you copied a history, you don't.
⚖️ Honest by design
Anything from your own machine can be faked — so we label that evidence as exactly what it is, and never call it verified until it's defended. No inflated claims, ever.
Getting started is free: scan your repos, build your public profile, and run your first live defense. For teams that hire, there's a dashboard and API to request and review defended profiles. Want it for your team? Book a call: https://cal.com/juan-redential/3...
The CLI is fully open source: https://github.com/redential/redential-cli - if you're technical and you can break the trust model, that's the feedback I want most. I want more contributors to help me improve the evidence and make a stronger credential.
👉 Try it now: npx redential scan or redential.com
Thanks for reading, excited to hear what you think! 🙌
Juan
You asked for someone to try to break the trust model, so here is where I think it gives.
The live defense is generated from the same history it is meant to validate. If I fabricate a history, the questions come from my fabrication, so I answer them easily, because I am the author of that fiction. Your line holds literally, if you did the work you remember it, but writing a convincing fake history is also work and I remember that too. The defense has no ground truth independent of the artifact under test.
The second half is the part that hurts your actual users. Someone who genuinely shipped a payments integration three years ago under NDA has forgotten the specifics. Someone who generated a repo last night has them fresh. The test rewards recency, and the people it penalises are exactly the senior devs whose invisible work you built this to surface.
Is question generation weighted by commit age, or does a 2019 repo get interrogated at the same depth as one from last month?
@abdullah_javaid3 You're right: at the Attested tier there's no ground truth outside the artifact, that's why it's the floor tier and labeled that way. What the CLI does is raise the price of the fake: signed commits can't be backdated without your key, replayed histories leave a committer-date signature the bundle ships, and the structural signals need real connected code (a webhook flow that verifies, writes and dedupes across files), not plausible-looking commits.
Also the session throws you a counterfactual (inverts a real fact from your history) and drills into your own answers, so a fake has to stay coherent under pressure. At that point faking it is basically.. doing work.
You got us on the recency thing. Today a 2019 repo gets the same depth as last month's. You basically wrote our next design issue. Wanna write it up for real? Issue #28 in the repo, that's exactly the contribution we want most.
Thanks for your feedback
Congrats on the launch. The interesting part here is the defense step, not the scanning. Anyone can generate a skills list from commit metadata, and once that's a market signal people will farm it. The live technical interview about your own code is the actual hard-to-fake bit, because you can't defend architecture decisions you didn't make.
Which raises the question I'd want answered before signing up: who's asking the questions, and how deep do they go? If it's an LLM prompted from the repo summary, a good bluffer with a rough understanding of the codebase probably gets through, and the credential is worth roughly what a CV is. If it's genuinely probing ("why did you pick exactly-once here instead of at-least-once with dedupe, and what broke when you didn't"), that's worth something.
Also curious how you handle the ghostwriting problem now that a big chunk of shipped code is agent-written. The git history says it was committed under your name, not that you understood it. Maybe that's fine and the defense catches it, but it seems like the main thing standing between this and a CV.
@aidan_codefox Depends on the evidence. From a CLI bundle the engine only sees metadata, so questions are architecture-level (why Redis, what breaks at 10x). From a connected repo it sees real files and mined fix history, so it gets specific, exactly your "why exactly-once here" type.
First question is deterministic from your detected capabilities; follow-ups are generated one at a time from the live transcript, so it drills into your last answer (capped at 3 levels per topic, server-side). Max 10 questions in 10 minutes, including one counterfactual that inverts a real fact from your history to catch people who agree with anything. Every positive verdict needs a literal quote from what you said, rules can only lower a verdict, and the model alone can never grant the top tier: Verified requires deterministic commit evidence. No human review today, that's the honest state.
On ghostwriting: we think the axis moved. The question isn't "did you type it" but "did you direct it and can you defend it". The bundle carries honest agent-involvement signals, and the defense tests exactly the part a ghostwriter can't sit for you.
Thanks for the feedback btw happy to hear more
@thys_beesman Yeah, so local evidence can't prove you lived it, so it's our weakest tier and labeled that way. Two things help tho: scan only counts commits YOU authored (a reviewer scanning that repo gets a thin profile), and claimed emails get checked against your verified ones. The hard-prepper gap is real. Our bet: memorizing months of someone else's decisions well enough to survive live follow-ups is almost as much work as doing the work. Narrows, doesn't close. Honest state of it.
Squashed/rebased repos: no "can't verify" verdict, you just get a thinner profile (fewer commits, capabilities still detected from the diffs). And squash-merge workflows are explicitly documented as benign in the forensics, what looks bad is years of history committed in one sitting. Migrated repos land as weaker evidence, not invalid. It's all in docs/schema.md so if you wanna poke holes, best kind of contribution for us.
One more thing: replayed histories usually leave every committer date clustered in one sitting even when author dates span years, and the bundle ships both spans. A careful forger can fake both dates though, git allows it. That's exactly why local evidence is the weakest tier by design and the live defense sits on top. We never claim to detect all forgery, we claim to label what we can't verify.
The local-scan-then-defend-live split is the right trust boundary here — self-reported evidence stays labeled unverified until you actually answer for it. Before trusting a profile though, how does the scan attribute authorship inside a repo where a chunk of the committed code isn't yours: vendored deps, generated files, or co-authored/pair commits? Curious whether those inflate the skills summary, or whether you filter to authored diffs before anything gets summarized and uploaded.
@hi_i_am_mimo Yep, filtered before anything is summarized. Skills only attribute from lines YOU actually added: vendored deps, generated files and other contributors' code never enter the analysis (author filter + path exclusions, all public in the repo). Co-authored commits inherit git's one-author-per-commit model, that's the honest limit. And it's all Attested-tier anyway: labeled claims, not verdicts.
The failure mode I would want to know about is the committer email.
Mine is wrong. My global user.email was a colleague's address for a long stretch of work, so those commits are credited to his GitHub account and my own graph is empty for all of it. The work is real, it sits in the history, and every tool that reads git hands it to someone else.
That is the same gap you describe with NDA work, except self inflicted, and far more common than people admit.
Since Redential runs locally, it could be the one tool that gets this right. GitHub has to trust the email because all it ever sees is the push. You are reading repos I actually hold. So does attribution come from the commit email, in which case it inherits the same wrong answer, or from the fact that the repo is on my machine and I can prove I have it?
Asking because if it is the second, that is a stronger pitch than the NDA angle for a lot of people.
@abdullah_javaid3 Attribution is by author email.
Possession can't be identity: everyone who clones a repo "holds" it, so possession-based attribution would let anyone claim any history they can download. Your case is the painful flip side: from the outside, "my commits carry my colleague's email" is indistinguishable from "I'm claiming my colleague's commits", and we refuse to guess.
So yes, today the CLI inherits git's wrong answer for that stretch, same as every tool. The one thing we add: you can claim multiple emails that are YOURS (they get checked against your verified addresses), which covers the common multi-email mess, just not the someone-else's-email one.
It's a real gap and more common than people admit, like you said. If you've got ideas for an honest fix (colleague attestation? signed retro-claims?), that's exactly the kind of thing issue #28 exists for.
@jpbelmo Two problems in there, and only one has a clean answer.
Going forward the honest primitive is the signature, not the email. An email is a string anyone can set in one config line. A signature is possession of a key. Attribute by key and treat the author field as a hint, and the whole class disappears for any repo where signing is on.
Backwards, your first instinct is the right one and the reason is worth naming. Colleague attestation works because the attester loses by lying. They are giving away credit for work they could have kept. Signed retro claims by the claimant fail for the mirror reason, the claimant gains by lying. Attestation is only sound when it costs the person making it, and that asymmetry is the thing you would be leaning on, not the crypto.
So the version I would trust is a countersignature from the address that owns the commits, scoped to a commit range rather than to a person. Does the CLI read signatures where they already exist, or is author email the only field it looks at today?
@abdullah_javaid3 Half yes, tbh: the CLI already reads signatures (the bundle ships signed count, ratio and key types, and they work as identity anchors), but attribution itself is author email only today. Key-based attribution for signing repos is the right north star imo, and your "the attester loses by lying" framing is the best articulation of the retro problem I've seen.
Two holes to bring along btw: the cost asymmetry weakens under collusion (credit can be traded between friends), and keys have their own retro problem (lost or rotated keys orphan your old signed work). So countersignatures probably need their own anchors too. Anyway, this thread earned its own issue in the repo. Wanna open it? Your name should be on this one.
@jpbelmo Both holes are real, and they are not the same kind of problem.
Collusion is not fixable at the attestation layer. Reciprocal credit trading shows up as a graph shape, two accounts attesting mostly each other. You catch it by reading the reciprocity ratio after the fact. Pricing it into each attestation just taxes honest pairs who really do work together.
Key rotation is your retro problem one level up. The usual answer is a continuity chain, where a new key signs a statement adopting the old one. History transfers without re-signing anything. Lost keys stay lost, which is right, because a claim nobody can prove should decay.
The issue is yours to write. Your repo, your roadmap, and you will scope it tighter than I would.
This is a really clever approach to the trust problem in hiring. One thing that would make it even more useful would be letting users pick which repos or specific commits get included, since someone might have a dozen personal projects but want to lead with their most relevant work for a specific role.
@kaplaneylu22927 Hey eylul! So today it's repo by repo: nothing enters your profile unless you scan and submit that repo, so you already control what's in.
We stopped there on purpose though: the moment evidence can be hand-picked commit by commit, it stops being evidence and turns back into a curated portfolio, which is kinda the problem we're replacing.
Curious about your use case though: is it more about hiding noise, or highlighting the most relevant work for a role? Because the second one is a presentation feature we could build without touching the evidence, and tbh it's a good idea.