WageCheck
A concept for informal workers: log what a job actually paid by neighbourhood, then check an offer before accepting it. The public build is a front-end concept, not a live dataset.
Overview
WageCheck is a concept product for informal workers. Workers log what a job actually paid, by neighbourhood. Before accepting a new job, they enter the offer and get a plain-language verdict: good deal, fair, or risky.
Pay information is informal and uneven. A worker can be offered ₹10,000 for electrical work and have no reference point for whether that is good, fair, or risky in that area. Most job platforms optimise for the employer's listing, not the worker's decision.
Goals
- Make the verdict the hero, not a dashboard of charts.
- Build trust by showing the sample size and the reasoning beside every verdict.
- Design mobile-first for workers checking an offer between jobs.
- Design the data story honestly before a backend or real dataset exists.
My contribution
- Product narrative and information architecture
- Visual identity and component system
- Responsive landing page and login route
- Production build and deployment
Design & engineering decisions
The stamp is the interface
The verdict is a rotated stamp with a short label, a sentence of reasoning, and the number of jobs behind it. It gives an abstract data product a physical, memorable object to organise around.
Paper, ink, rust, amber
The palette borrows from noticeboards and printed receipts rather than fintech dashboards. The warm paper surface makes the product feel human and local, while the rust and amber accents carry emphasis without relying on green/red traffic lights.
Show the sample size
A verdict without context is a guess. The card always pairs the result with the number of jobs logged in that neighbourhood, which makes the confidence of the answer visible.
State the limits in the product
The public build is a front-end concept. It does not pretend to have a live dataset, an account system, or a working wage database. The next step is the data model and moderation, not more interface.
Architecture
- The repository contains the marketing page and a login route; there is no API, database, or verdict engine yet.
- The figures in the hero are sample content for the concept, not measured outcomes.
- The build is deployed on Vercel.
Implementation
- A two-column hero pairs the product promise with a physical-looking verdict card.
- The stats strip uses large numerals and short labels to establish the product's promises at a glance.
- The process section turns a data product into three concrete steps: log the job, history builds, get a verdict.
- Hard shadows and 2px borders create a printed, tactile feel without gradients.
Challenges
A data product without data
The concept needs to feel credible before the dataset exists. The solution was to make the reasoning and sample size visible in the interface, and to label the build as a concept rather than implying a live service.
Trust without false precision
A single number can look more authoritative than it is. The verdict uses three broad categories and a sentence of context, not a decimal score.
Outcome
Live at wagecheck-woad.vercel.app. The landing page and login route are implemented. Wage logging, verdict calculation, and persistence are not — this is intentionally a front-end concept.
What I learned
Trust is a design material.
Showing the sample size next to the verdict does more for credibility than another chart.