Two-sided hospitality hiring with sequenced onboarding and honest partial-ship
Scopelyt built employee and employer portals on one API for catering and hospitality hiring. Routes gate by role. Employee onboarding runs as five server-enforced steps before the product treats a candidate as ready. Employer company profile onboarding is API-backed. Job posting, candidate search, and subscription checkout screens exist in the client only; those API workflows are not shipped.
- Industry
- Catering · hospitality
- Type
- Two-sided hiring
- Portals
- Employee · employer
- Auth
- OTP · Google · refresh
01 — Problem
Catering and hospitality hiring needs two portals that share one product truth, not two apps that drift apart. Candidates should not appear hire-ready until every onboarding step is complete, and employers should not land on job search or billing screens the server cannot defend. The product has to enforce a fixed employee path (preferences, history, CV) while letting employers set up company profiles without the UI pretending candidate search or subscription checkout is live backend work.
02 — Constraints
- Employee and employer routes share one API with role gates, not separate backends that can diverge.
- Onboarding steps must be enforced on the server and mirrored in the client router. UI gating alone is not enough; completion flags on the server are the source of truth.
- Job posting, candidate search, and subscription checkout exist as client screens only. Copy and portfolio claims must never describe those paths as finished API workflows, searchable indexes, or payment integrations.
03 — Responsibilities
- Built a two-sided hiring product for catering and hospitality: employee and employer portals on one API, with routes gated by role.
- Authentication covering registration, email OTP, password and OTP login, Google sign-in, refresh tokens, and password reset.
- Employee onboarding as sequenced steps in fixed order: job preference, education, employment history, social links, and CV upload. Completion flags enforced server-side and reflected in the client router so candidates cannot skip ahead by URL.
- Employer company-profile onboarding shipped with API support.
- Job posting, candidate search, and subscription checkout built as client screens to show product shape. Those workflows are not implemented in the API and must not be claimed as shipped backend work.
04 — Architecture
- One REST API serves both employee and employer portals. Role determines which route handlers and screens are reachable.
- React portals (employee and employer) with client routing that mirrors server onboarding completion state.
- MongoDB persistence for user, profile, and onboarding progress. Server completion flags drive which onboarding step is active.
- Auth surface spans registration through password reset, with refresh token rotation and Google sign-in alongside email OTP paths.
- Employer-side job posting, candidate search, and subscription checkout UI exists ahead of API work. Portfolio copy treats them as exploratory screens, not production hiring or billing flows.
05 — Technical decisions
- Server completion flags are the source of truth for employee onboarding progress. The client router follows those flags instead of trusting navigation alone, so direct URL entry cannot bypass unfinished steps.
- One shared API with role gates instead of split employee and employer backends. Same deployment, different guards; reduces drift between what candidates and employers see as product truth.
- Employer job posting, search, and checkout screens shipped in the client before API workflows exist. That shows UX direction without padding backend or payment claims in the portfolio record.
06 — Implementation
- Employee onboarding ships as five ordered steps: job preference, education, employment history, social links, CV upload. Each step sets a completion flag on the server; the router only advances when the flag is set.
- Auth methods live end to end: registration, email OTP, password login, OTP login, Google sign-in, refresh tokens, password reset.
- Employer company profile onboarding is the API-backed employer path. Job posting forms, candidate search views, and subscription checkout UI are client-only; no public OpenAPI, demo URLs, or payment provider integration is part of this case.
07 — Trade-offs
- Client screens for job posting, candidate search, and subscription checkout communicate product intent without backend completion. The trade is portfolio honesty over inflated scope; those surfaces stay explicitly non-API in copy.
- Dual enforcement (server flags plus client router) adds coordination between API and frontend, but prevents candidates from skipping onboarding via bookmark or manual navigation.
08 — Result
A hiring product record with honest scope: strong auth, sequenced employee onboarding, and employer company profile shipped where the API supports them. Job search and subscription checkout stay visible as client UI only, called out instead of padded. Proof Scopelyt can shape two-sided marketplace architecture (role gates, shared API, server-enforced onboarding) and document partial-ship boundaries without inventing demos, adoption metrics, or finished billing backends.
09 — Stack
2
3
4
5
> |
// Client builds get the same clarity-before-code bias. Lock scope, then execute.
// Same pod. Weekly demos. You own what ships.
