A hiring platform, built end to end.
WorkEthix is a two-sided recruitment product — employers post roles, candidates apply, and an admin layer runs the whole thing behind them. I was the founding engineer: empty repo to a live product, front-end and back-end, mine to own. This is the story of what that actually involved.
The marketplace — three roles, one platform
The product is a two-sided marketplace with an operations layer on top. Every role sees a different surface, but they're all backed by the same data model with strict per-user access — so the hard part isn't three separate apps, it's one system that shows each person only what they're allowed to touch.
- Employer — posts jobs, manages listings, and reviews incoming applications, with a notification on each one.
- Candidate — builds a profile, browses roles, and applies, with application status tracked from submitted to reviewed.
- Admin — a control panel over jobs, reviews, case studies and users: the operations layer that keeps the platform running.
Auth and access — enforced in the database
A product like this lives or dies on access control. I built the full authentication stack — signup, email verification, login, forgot and reset password, plus Google sign-in alongside email and password — with hashed credentials and signed session tokens. But the decision that matters is where access is enforced.
Rather than trust the application layer to remember every rule, I pushed access control down into the database itself with Postgres row-level security. Each row carries its own policy: an employer can only see and edit their own jobs, a candidate can only read published ones, an admin can see across. Even if a bug slipped through the API, the database itself refuses to hand over data the caller isn't entitled to. Security by default, not by discipline.
The API — a typed action behind every click
The whole product runs on typed route handlers — auth, jobs, applications, reviews, notifications, newsletter — in TypeScript against the Postgres backend. The flows that mattered most were the ones that touch more than one party:
- Job management with per-listing endpoints and end-to-end application tracking.
- A notification pipeline that emails the employer the moment a new application lands.
- Reviews and case studies managed through the admin surface.
- Newsletter subscription wired to a transactional-email backend.
The front-end — polished and responsive
The last layer is the one people actually judge you on. It's a Next.js App Router front-end in TypeScript, built mobile-first and fully responsive, with light and dark theming and considered motion rather than decoration. A consistent, accessible component layer keeps every surface — employer, candidate, admin — feeling like one product, and rich-text editing handles job descriptions and content without fighting the user.