LinkHR

Overview

LinkHR started from a simple frustration: job boards optimise for volume, not fit. Candidates fire off dozens of applications into silence, and recruiters drown in résumés that were never a match. LinkHR reframed hiring as a two-sided matching problem — candidates and employers each express interest, and a conversation only opens when both sides do.

Key Features

• Two-sided matching: A swipe-based discovery flow for both candidates and recruiters, with messaging unlocked only on a mutual match — filtering noise out before it reaches anyone’s inbox.
• Structured candidate profiles: Skills, experience, and preferences captured as structured data rather than free-text CVs, so matching could rank on something better than keyword overlap.
• Mobile-first product design: The whole experience was designed for the phone first, since that’s where the discovery loop actually happens.
• Recruiter-side pipeline: Role posting, candidate shortlisting, and match management from a single dashboard.

Technologies Used

• Python backend: REST API for profiles, roles, matching, and messaging.
• React front-end: Candidate and recruiter interfaces sharing a common component layer.
• Vercel: Deployment and preview environments.

Challenges and Learnings

The technical build was the easy half. The genuinely hard problem was the cold start — a matching marketplace is worthless to the first candidate who joins and worthless to the first recruiter, and solving that is a go-to-market problem, not an engineering one. I learned more about scoping an MVP, pitching, and sequencing a two-sided launch here than in any project where the code was the bottleneck.

Outcome

LinkHR is paused rather than shipped — the product reached a working MVP but never cleared the marketplace liquidity problem. I’ve kept it in the portfolio deliberately: it’s where I learned to tell the difference between a hard engineering problem and a hard business one, and that lesson has shaped how I scope every product I’ve built since.