Launched this week
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.
Redential
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?
Redential
@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.
Redential
@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
Redential
@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.
Redential
@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.
Redential
@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?
Redential
@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.
coming at this as a CTO rather than a candidate: the "never your code, only a summary" pitch protects the code, but the summary itself can still be a leak. "webhook flow with signature checks and duplicate-payment protection, connected to auth via X" tells a competitor exactly how your payments system is architected, even with zero lines of code shown. that's the kind of detail I'd actually care about in an NDA, not the literal source. does an employer get any say over what a former engineer's scan surfaces about company repos, or is that entirely the individual's call once they have local access to the history?
Redential
@galdayan hey gal, thanks. one factual fix first: the bundle never says "connected to auth via X", that example overshoots. What actually leaves is a closed-vocabulary slug (payments/payment-webhook-flow) and that's literally the whole disclosure. No architecture graph, no system connections, nothing.
So: the vocabulary IS the ceiling. it can only name industry-standard patterns (the taxonomy is public in the repo), so what gets out is "their front door has a lock" level stuff. Anything bespoke straight up can't be expressed, there's no slug for it, and adding one takes a public discussion plus schema ceremony. The leak surface is fixed and auditable, not open-ended.
On employer say: honest answer, nope. It's the individual's call, same as listing skills on a CV always has been, and the scan makes them confirm they're authorized. the way we think about protecting the company side isn't a veto, it's the ceiling: the tool literally can't surface more than CV-level facts. Does that cover what you'd actually worry about, or is there a case you're seeing that I'm not?
Btw this is exactly the feedback that's been shaping the product all week, keep it coming. And give the scan a try on any repo, takes a minute, no account: npx redential scan
@jpbelmo fair, thanks for the correction - I was extrapolating past what the tool actually surfaces. a closed vocabulary that can only point at public-taxonomy patterns is a genuinely different risk profile than a free-text summary, and the schema-ceremony friction for adding new slugs is a smart way to keep it that way on purpose rather than by accident. no employer veto makes sense too, same logic as a CV. appreciate you walking through it in this much detail.
Redential
@galdayan Appreciate you pushing on it, this thread made the docs better (seriously, half our FAQ came from questions like these this week). And hey, if you ever want a look at the hiring side of this, happy to walk you through it, no pitch: https://cal.com/juan-redential/30min