Building for signal, not volume
Crew started from a simple observation: many hiring platforms optimize for traffic, not trust. That usually leads to noisy listings, weak applicant quality, and low confidence on both sides.
I built Crew as a code-first hiring portal where candidate signal comes from real technical activity, and hiring access is gated through a review process. The goal was to create a system that feels reliable in production, not just impressive in a demo.
Product principles
Crew is shaped by four product principles:
- Public discovery should stay frictionless.
- Applications should require verifiable identity.
- Posting jobs should require reviewed hiring access.
- Workflow state should be explicit and auditable.
These principles helped keep decisions consistent across auth, role design, UI, and moderation.
What Crew solves
Traditional job boards tend to fail in three places:
- Unverified job posts reduce candidate trust.
- Resume-heavy applications hide actual engineering signal.
- Workflow ownership is unclear between recruiters and platform admins.
Crew addresses this with a strict trust model:
- Anyone can browse jobs without login.
- Applying requires GitHub authentication.
- Hiring teams must request access before posting.
- Admins control approvals and moderation.
Core capabilities
1. Public jobs with GitHub-only applications
Jobs are visible to everyone, which helps distribution and SEO. But applications are accepted only from authenticated GitHub users, reducing spam and improving applicant quality.
2. Hiring access request workflow
HR users do not get posting rights by default. They submit a request with organization details, and admins approve or reject it. Role assignment is updated only after review.
3. Role-based governance
The platform enforces clear role boundaries:
- Candidate: browse and apply.
- Hiring team: manage jobs and applicants.
- Admin: approve hiring access, moderate listings, manage user roles.
This keeps sensitive operations restricted and reduces accidental misuse.
4. Developer-first candidate context
Instead of relying only on self-reported resumes, Crew surfaces practical GitHub signal:
- Repository activity
- Language usage
- Profile metadata
- Reputation score
This gives hiring teams immediate technical context before deep screening.
5. Job lifecycle controls
Jobs follow a state-driven lifecycle to keep moderation and visibility predictable:
Draft -> Review -> Live -> Closed
This model supports staged publishing, admin oversight, and safe closure without ambiguous status transitions.
6. Auditability and operations
Crew includes operational details that matter in real environments:
- Action-level audit logs
- Applicant status tracking
- CSV export for downstream recruiting workflows
- Expiry handling for stale postings
Technical implementation
Crew is built with a server-first architecture focused on reliability and maintainability.
- Framework: Next.js App Router
- Mutations: Server Actions
- Database: PostgreSQL (Neon) via Prisma
- Authentication: NextAuth with GitHub provider
- UI: Tailwind CSS, Lucide icons, Radix primitives
- Analytics: Vercel Analytics
Key engineering decisions:
- Keep role checks on the server, not only in UI conditions.
- Model workflows explicitly in data, not as ad-hoc booleans.
- Prefer clear moderation queues over implicit auto-approval paths.
Why this matters
Crew is not trying to be the largest hiring marketplace. It is designed to be a trustworthy one.
When trust rules are encoded in access control, data workflow, and moderation, platform quality becomes a system property rather than a manual effort.
That is the part I value most about this build: not just a polished interface, but a hiring product where signal, accountability, and user confidence are built into the foundation.