Navigos Talent One
Navigos Talent One is the employer recruitment platform that Navigos Group's clients use to post jobs, screen candidates with AI scoring, build hiring campaign pages, and track applications from search to onboarding. Four engineering squads ship features on this codebase in parallel.
203K
Lines of Code
15
Packages
4
Squads
2800+
Components
203K lines of TypeScript. Four teams. Constant collisions.
Four engineering squads build features on a 203K-line TypeScript monorepo with 15 packages. When one squad changed shared state, another squad's feature would break without warning. Merge conflicts stacked up because everyone touched the same files. The platform serves users in multiple languages, but translation keys were plain strings with no validation, so typos only surfaced in production when a user saw a missing label. None of the off-the-shelf state management options solved the core tension: teams needed isolation to ship independently, but they also needed to share data like permissions, authentication, and user preferences across module boundaries.
Application tracking with AI match scoring
Custom state that isolates teams but shares what matters
To solve the collision problem, I built a state management system on top of React's useSyncExternalStore and Immer. Each squad's state lives in its own scope so changes can't leak into another team's features, but shared data like permissions and authentication flows through app-wide stores that every module can subscribe to. Components only re-render when the specific values they care about change, so one team updating their state doesn't trigger unnecessary renders across the rest of the platform.
The translation issue was solved the same way: the system uses plain TypeScript objects with type-safe keys, so developers get autocomplete for every translation string and the compiler catches typos before code reaches production. Feature modules are lazy-loaded so the browser only downloads code for the section the user actually opens, and route prefetching starts loading the next likely page while the current one is still visible. The monorepo itself uses git submodules to give each squad its own feature scope, which cut down merge conflicts because teams stopped editing the same files.
Block-based landing page builder
Job management with live metrics
AI-powered candidate recommendations
Candidate AI evaluation profile
What the squads shipped
Employers type a job title, AI writes the posting
The AI job description generator takes a title and a few bullet points and produces a structured posting ready to publish. Every incoming application gets scored by AI across skills, experience, and education, so recruiters see a match percentage on every candidate without reading the full CV first.
Hiring campaigns that used to need a developer
Employers build their own recruitment campaign pages using a block-based editor with responsive previews, template system, theme colors, and draft/publish workflows. Uploaded images are automatically converted and resized to WebP at multiple breakpoints so campaign pages load fast on any device. Before this builder existed, every campaign page required developer time to create and deploy.
Every application from search to onboarding in one pipeline
The ATS tracks candidates across multiple pipeline stages with AI match scoring, bulk operations, and collaborative review workflows. Moving a candidate between stages uses optimistic updates so the UI responds immediately while the server confirms in the background, which matters when recruiters are processing dozens of applications in a session. Four engineering squads built different parts of this system in parallel, and the custom state architecture kept their code from colliding.
Four teams shipping without waiting for each other
Each squad owns its features and deploys without waiting on the others. When a user logs in, switches language, or changes roles, the relevant content updates instantly without a full page reload because the state system re-renders only the affected components. Route prefetching and lazy-loaded modules mean the next page is often ready before the user clicks, and optimistic updates make every action feel immediate even on slower connections. Permissions are checked through one shared system across all modules, so no team had to build their own access control from scratch.
0
Engineering Squads
Each ships features without waiting on the others
0K
Lines of TypeScript
Spread across 15 packages in one monorepo
0
Page Reloads Needed
The screen never goes blank, no matter what you do
0
Shared Permission System
Every module uses the same access control logic