Sid Mehta Works
Ledger

Ledger

Project details

Year

2026

Client

Exercise · concept

Role

Design · Front end

Tools

React · Claude · Design tokens

Live

Run the prototype

Project highlights

0

external tabs to reach a verdict

5

material checks, scored apart

0

contrast failures, light and dark

Overview

A submission review layer for hiring. Every candidate's repository, live demo, screenshots and walkthrough live in one reviewable surface, with scoring that separates what a candidate shipped from what they merely claimed.

Agentic AI · Design SystemsDesign · Front end · Exercise · concept

A time poor reviewer should be able to understand one submission, inspect the evidence behind it, and reach a fair decision without leaving the page. Everything below follows from that sentence.

The legacy tool, running. Four links per candidate, a prototype that fails to load, and a review form that asks for a verdict on work the reviewer can no longer see.

Memory becomes the system. A reviewer is asked to hold four tabs and a broken preview in their head, and then to rate something they half remember, twenty three times in one sitting. Every decision after the first is made against a fading copy of the work.

One surface. The repository, the live demo, the walkthrough and the README are tabs on the submission rather than tabs in the browser, and the prototype runs inside the page being scored.

Evidence, then a decision. What the repository actually contains sits beside what the candidate claimed, and the reviewer advances to the next submission without losing the thread.

Calibration before anyone moves forward. Two reviewers disagreeing is surfaced as a thing to resolve, not averaged away, and the finalists leave as a packaged handoff.

Open the Ledger prototype

The real thing, running in this browser. Review a candidate, score them against the rubric, and take the shortlist to a handoff.

Completeness is counted separately from quality, so a missing README never reads as weak work.

The scorecard: four criteria scored nought to four, each point carrying a written behavioural description

A claimed stack becomes an inspectable one. What the candidate said, against what the repository shows.

Repository evidence separated from candidate claims, each line traceable to a file

A broken deploy is not the same as absent work, and the interface refuses to score them alike.

The failed deployment state, which explains what broke and keeps the rest of the evidence usable
The missing material state, written to be useful to the reviewer and to the candidate

The system view is part of the prototype rather than a document beside it: tokens, component anatomy, the state matrix and the accessibility contract are all inspectable from inside the thing they describe. Contrast is audited in a script that runs against both themes and reports zero failures.

The system view showing colour tokens, component anatomy and the full state matrix
The mobile review layout, evidence stacked first with a sticky review dock
The light theme of the system view
Reflection

The decision I would defend hardest is separating whether a submission is complete from whether it is good. Those two questions arrive at the same moment and a single star rating collapses them, so a candidate who shipped strong work with no README scores like a candidate who shipped nothing. Pulling them apart cost a column of screen and made every score afterwards mean something narrower and more honest. The one I would revisit is the anchored rubric. Writing behavioural descriptions for every point on every criterion is the reason a reviewer can score consistently at submission nineteen, and it is also the heaviest thing on the page. I would want to watch somebody use it for an hour before defending the weight.

Back to top
Next project Obin An agent writes the credit memo in four minutes. Then an analyst checks every number in... Back to top