Inspiration
Someone can spend years building hiring intuition — who fits a seed-stage team, how to read a portfolio, what makes outreach feel human, which signals matter for a founding engineer vs. a senior PM. They know the roles they need to fill, the candidates they want to reach, the follow-ups that should have gone out last week, and the story they want every hire to understand about the company.
But then they open a blank ATS, a spreadsheet, or a chain of disconnected tabs — LinkedIn, Gmail, Calendar, notes, job descriptions — and the work often dies at the first blank screen.
Before there is a qualified pipeline, there are barriers: expensive enterprise recruiting software, fragmented tools, manual copy-paste between inboxes and trackers, no shared memory across searches, and AI products that hide context inside opaque databases instead of letting recruiters inspect or own their work. The first lesson is not judgment. It is setup friction.
This pattern repeats quietly. A founder is also the hiring manager. A lean startup has one recruiter doing sourcing, screening, scheduling, and outreach alone. A community organization wants to run a fair search but cannot afford a full recruiting stack. A hiring manager has strong intuition but no time to operate five tools at once. The deeper issue is not a lack of talent in the market. It is the production gap between knowing who you want to hire and running a living pipeline that compounds over time.
The access gap is not only about connectivity. It is about whether smaller teams get the same leverage larger organizations buy with headcount and software budgets. Jobraker Recruiter was built for that gap: a local-first AI copilot that helps lean teams source, screen, pipeline, and outreach from one workspace — with hiring context that stays on their machine as plain Markdown they can read, edit, and trust.
What it does
Jobraker Recruiter is a desktop recruiting copilot for lean hiring teams. Instead of leaving recruiters alone with disconnected tabs and empty trackers, the assistant reasons over the user's request, loads the right skills, calls structured tools, reads local knowledge, and helps produce inspectable recruiting artifacts: candidate records, role briefs, outreach drafts, meeting notes, and pipeline state.
A typical workflow:
- A recruiter asks: "Source senior product designers in Lagos with 5+ years SaaS experience and strong systems thinking."
- The copilot plans the search, uses enrichment providers, and adds candidates into the local pipeline.
- The home dashboard surfaces live KPIs, top matches, Gmail replies, and calendar interviews.
- The recruiter opens a candidate, reviews fit signals, drafts outreach, and moves the stage forward.
- Background agents can keep sourcing or follow-up work running while the recruiter focuses on decisions.
The output is not a one-off chat answer. Jobraker Recruiter produces a working recruiting system: roles, candidates, pipeline columns, analytics, and a knowledge vault that grows with every search.
How we built it
Jobraker Recruiter is an Electron desktop app built with React 19, TypeScript, Vite, Tailwind CSS, and a nested pnpm workspace (apps/x). The product shell combines chat, file tabs, recruiter dashboards, meetings, email, and background agents in one local-first workspace.
The method is deliberately not "generate one big answer." The assistant works through a bounded tool-using workflow:
user goal → skill selection → tool call → structured result → refinement → saved artifact
Agentic recruiting architecture
The copilot runs through a skill-and-tool loop:
- Skills layer — domain guidance for recruiting workflows: app navigation, sourcing, outreach, live notes, background tasks, browser control, MCP integrations, and more.
- Builtin tools — file operations, knowledge search, Gmail/Calendar access, browser control, elastic retrieval, background-task scheduling, Composio integrations, and recruiter UI navigation.
- MCP + Composio — connect external systems without hard-coding every integration.
- Local knowledge vault — Obsidian-compatible Markdown notes with backlinks, so hiring context compounds instead of resetting every search.
Recruiter product surface
The recruiter module gives lean teams a real operating system, not just a chat box:
- Home — live KPI cards, top matches, pipeline overview, Gmail inbox, and calendar agenda
- Sourcing — LinkedIn URL enrichment through PDL and Enrich.so
- Candidates / Pipeline / Analytics — dashboards backed by local persisted state, not mock seed data
- Roles — open-role tracking with applicant quality signals
Data persists locally under ~/.jobraker-recruiter, including candidates, stages, notes, pipeline boards, and API configuration.
Model layer
Jobraker Recruiter supports multiple providers, including Gemini and local Ollama models such as the Gemma family. That matters for teams who want cloud intelligence for hard reasoning tasks, or local inference when privacy, cost, or offline use is important. Model config lives in a simple local JSON file — no hidden platform lock-in.
Why local-first matters
Most recruiting tools treat every search as a cold start. Jobraker Recruiter keeps long-lived knowledge instead:
- hiring context accumulates over time
- relationships between people, roles, and companies stay explicit
- notes are editable by the recruiter, not trapped inside a model
- everything lives on the machine as plain Markdown
That design makes the assistant's work visible, auditable, and portable.
Challenges we ran into
Scope. Recruiting spans sourcing, enrichment, screening, scheduling, outreach, analytics, and knowledge management. The system needed typed tools, recruiter screens, and skill boundaries instead of one vague chatbot.
State across views. The home dashboard, recruiter screens, and copilot all needed the same live candidate and role data. I solved this with shared local state loading, storage change events, and metric snapshots for real trend deltas instead of hardcoded KPIs.
Safe iteration. Enrichment, outreach, and file edits all needed guardrails: approval-gated destructive actions, bounded reads/writes, and explicit UI navigation tools so the model acts inside the app instead of hallucinating state changes.
Integration friction. Gmail, Calendar, MCP servers, enrichment APIs, and optional Elastic retrieval each have their own setup path. The product had to make those connections optional but real — not demo-only props.
Lean-team UX. Enterprise ATS products optimize for headcount. This product had to optimize for one recruiter wearing five hats: fast scanning, command-first navigation, visible work state, and dense but calm UI.
Accomplishments that we're proud of
- Built a full recruiter operating surface — home, sourcing, candidates, pipeline, roles, and analytics — inside a local-first Electron copilot
- Replaced mock dashboard data with real persisted pipeline state, live KPI calculations, and weekly metric snapshots
- Added LinkedIn enrichment through PDL and Enrich.so with API-key settings and a sourcing queue
- Wired the home dashboard to real Gmail threads and synced Google Calendar events, not placeholder inbox/agenda cards
- Designed an agentic architecture where the copilot can navigate the app, edit knowledge, run background tasks, and call external tools through MCP/Composio
- Kept hiring memory transparent as Markdown in an Obsidian-compatible vault instead of hiding it in a proprietary database
The important result is not a benchmark score. It is a working interaction pattern: a lean hiring team can describe a search, inspect the candidates produced, refine through natural language, and keep context compounding in the same workspace.
What we learned
A recruiter does not only need a generated message. They need a loop:
search → inspect → compare → outreach → schedule → remember → repeat
Dream Studio taught me that the translation layer between imagination and artifact has to be inspectable. Jobraker Recruiter applies the same principle to hiring: the assistant must not only answer — it must leave behind editable records, visible pipeline state, and notes the recruiter can trust.
I also learned that digital equity in recruiting is not just about access to profiles. It is about whether smaller teams get compound hiring memory, agentic workflow support, and integrations that were previously bundled into expensive enterprise stacks.
What's next for Jobraker Recruiter — AI Hiring Copilot
- Deeper Elastic / hybrid retrieval for semantic candidate-role matching at scale
- Stronger background-agent templates for sourcing, follow-up, and pipeline hygiene
- Richer outreach analytics tied to real Gmail reply signals
- Full local-first model paths for more recruiting workflows on Ollama / Gemma
- Team workspaces with shared vault sync while preserving local ownership
- Broader enrichment providers and resume parsing for faster candidate intake
Team: Miles — solo builder. Product design, AI workflow architecture, Electron + React implementation, recruiter UX, enrichment integrations, and demo preparation.
Built With
- anthropic
- composio
- deepgram
- elasticsearch
- electron
- elevenlabs
- enrich.so-api
- esbuild
- firecrawl-api
- google-calendar-api
- google-gemini
- google-gmail-api
- mcp-(model-context-protocol)
- motion
- node.js
- ollama-(gemma)
- openai
- openrouter
- people-data-labs-api
- pnpm
- radix-ui
- react-19
- tailwind-css
- typescript
- vercel-ai-sdk
- vite
Log in or sign up for Devpost to join the conversation.