Context
NXT wanted to test an idea: hiring where companies and candidates match the way people already expect matching to work everywhere else. What they needed first was not a platform, it was proof. Something real enough to put in front of users, built fast, but not so disposable that a positive result would mean starting again.
Two of us built it, in five months, and I was one of the two.
How it was built fast
OAK’S LAB maintains a platform base: a Turborepo with authentication, a Prisma database package, tRPC wiring, a component library, infrastructure as code and CI already solved. A new product starts from that instead of from create-next-app.
Working that way is its own discipline. Half of my first weeks were spent deleting: stripping the base features this product would never need, so the codebase stayed about hiring rather than about the platform it came from. The rest was extending the shared layers rather than forking them, which is the part that decides whether the next product benefits or pays.
What I built
I worked across the whole stack, from the Prisma schema and migrations through the tRPC endpoints to the screens and the shared component library.
- Onboarding for three personas. Companies, candidates, and candidates changing what they are looking for, plus the redirect guard that decides where a half-finished user lands when they come back. This is the least glamorous part of a product and the one that breaks the most quietly.
- The company side. Creating a company, its profile and account settings, inviting members and accepting invitations (including the awkward case of an invite link opened by someone already logged in), assigning hiring managers, and removing a member whose jobs still exist.
- The candidate side. The candidate account, the profile, the public preview a company sees, the experience and education forms, and the “what I am looking for” form that drives matching.
- Jobs and applications. Job creation and cloning, locations, applying as a candidate, adding an existing candidate to a job, and re-running pre-screening when a job’s requirements change, so the pipeline reflects the job as it is now rather than as it was posted.
- Notifications and chat. Transactional email for new jobs and status changes with the templates behind them, and the chat between a company and a matched candidate.
- Admin and platform polish. A global admin area, profile switching for admins, the file-upload flow, and the loading and empty states across every table in the product.
Why an end-to-end typed stack suits an MVP
The base’s choice of tRPC over Prisma earns its place on a product like this. On an MVP the requirements move every week, and the most expensive bugs are the boring ones: the frontend and the backend disagreeing about a field that changed on Tuesday. Here a change to the data model surfaces as a compile error in the UI instead of an exception in production.
That is what makes an MVP safe to steer. Renaming a concept because user testing said so becomes a half-hour job with a type checker pointing at every call site, not a bet.
I applied the same logic to testing: Playwright covering the few flows that must never break, and no time spent on unit tests for code that was likely to be deleted.
Outcome
A working hiring platform in production on Google Cloud, built by a pair rather than a team, and structured so the people who picked it up afterwards could extend it rather than rewrite it.