Redential

A developer credential that proves what you built, NDA safe.

Open Source

Developer Tools

Career

Visit WebsiteSee on Product HuntGithub ⧉Twitter ⧉

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?

Congrats on the launch!!

Verification is the interesting part here. How do you prove someone actually built what they claim without access to private repos?

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.

This hits close to home — I'm self-taught and just launched my first product today. My git history is basically the only proof I have that I actually learned to build something real, since I don't have a traditional resume line to point to. Turning that into something shareable is such an obvious-in-hindsight idea. Congrats on the launch!

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.

Dev credential based on what you actually built is better signal than certifications tbh. GitHub activity shows some of this but not the full story. How do you verify the contribution is genuine?

reading git history instead of asking people to write a portfolio is a genuinely good idea, most portfolios are curated fiction anyway. the "defend it live" step is what sells it for me - that's the part that actually separates someone who understands their own commits from someone who just merged a PR someone else wrote.

A really interesting approach to the problem. How (if at all) can you prove past work after leaving a company and losing access to its code? Also, can employers view shared profiles freely?

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.

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.

@jpbelmo How does the CLI handle private repos with strict compliance rules, and is there any plan to support more platforms beyond GitHub?

What happens when you work in close enterprise git mostly and you are not allowed to install any unapproved apps.

The interesting tension here, git history proves a history, not that you're the one who lived it. Someone could scan a repo they only reviewed, then still answer basic questions about it correctly if they read the PRs closely enough. The live defense narrows that gap but probably doesn't close it for someone who prepped hard. More practical question: what happens with squashed/rebased commits or a repo migrated from a different VCS? A lot of real production repos have messy or rewritten history curious if that shows up as "can't verify" or if it just quietly produces a thinner profile.

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?

Congrats on shipping. You said the git-history trust model is what you want people to try to break, I got curious about the dashboard side instead: once a team requests a defended profile, is that visible only to the team that requested it, or could a different team account pull up someone else's pending review before it goes public?