The problem
Recruitment tools still look like old enterprise software. The people using them are already on phones. A recruiter scans a list on a desktop. An applicant records a short intro on a phone.
Happly had to feel like a consumer app and still carry the work: roles, applications, chat, and a screen a recruiter can use on a real pile of candidates.
How I think
There was no product team to wait on. I ran design, the web app, the API, screening, and production myself. That is how a full platform landed in about six months, around 42,800 lines.
Screening had to be cheap enough to run on a real job, and still show up on the applications page. I priced it before I shipped it. About $1.60 to screen 30 applicants. Speech is what you pay for. The judgment on top of the transcript is cheap. Results expire after 90 days, so storage does not grow with every job you have already reviewed.
Design
Two people share one product, and they are not on the same device. The recruiter needs a list they can scan and a candidate they can open without losing the list. The applicant needs to record and watch video. One shell does both: bottom navigation on a phone, a rail on a desktop, and a list that sits beside the detail or stacks under it.
Color starts from one brand seed, and the rest of the palette is built from it. A new seed is a different look. The plan was to later color each company from its own brand, so that space felt native to them.
AI Assist lives on that same page. A score, a short summary, and strengths and concerns as chips, so the recruiter can keep moving. If one applicant fails, the rest of the batch still finishes.
The intro is the application. Playback fits the screen the person is actually on, and upload is in pieces, because phone video is large.
Architecture
A screening job can take minutes. I kept it off the main API so the app would not sit on that request.
The web app talks to a .NET API. Auth0 holds login and roles. Video, résumés, and images stay with the product. Chat is created when someone applies, so a conversation belongs to that application.
For each applicant, a separate service turns the video into text, reads the résumé, and returns a score from 0 to 100 with a summary, strengths, and concerns. A second look at the same job reads the saved result, so it does not pay again.
If I built the scoring step today, I would use Jev. It returns a typed decision your code can use: a score, a choice, or a yes or no, each with a confidence. That is the contract this screen needed, and it is cheap enough to run on every application now.
Production
The product ran on a VPS: the app, the API, and the files, with versioned builds and a normal redeploy. Screening sat beside it as its own service, so a long video job could not take the API down. Video links are signed, so they still had to work once the site was on HTTPS. That is the sort of thing you only catch off your laptop.
The owner wound the project down. The live demo is no longer in production.