Jobraker Recruiter

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

Inspiration

Someone can spend years building hiring intuition: who fits a seed-stage team, how to read a portfolio, what makes outreach feel human, and which signals matter for a founding engineer compared with a senior product manager.

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 applicant tracking system, 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-and-paste between inboxes and trackers
• No shared memory across candidate searches
• AI products that hide context instead of helping recruiters inspect, refine, and own their work

The first challenge is not hiring judgment. It is setup friction.

This pattern repeats quietly. A founder is also the hiring manager. A lean startup has one recruiter responsible for sourcing, screening, scheduling, and outreach. A community organization wants to run a fair search but cannot afford a complete recruiting stack. A hiring manager has strong intuition but no time to operate five tools at once.

Jobraker Recruiter was built for that gap.

It is a web-based AI recruiting workspace that helps lean teams source candidates, evaluate fit, manage hiring pipelines, draft outreach, and preserve recruiting context from one place.

The product uses Supabase for authentication and core workspace data, Vercel for deployment, AWS DynamoDB for operational workflow state, and an OpenAI Codex-powered assistant architecture for executing recruiter requests inside the application.

What it does

Jobraker Recruiter is an AI recruiting workspace for lean hiring teams.

Instead of leaving recruiters alone with disconnected tabs and empty trackers, the assistant helps create inspectable recruiting artifacts:

• Candidate records
• Role briefs
• Candidate fit assessments
• Outreach drafts
• Pipeline stages
• Sourcing notes
• Recruiting activity
• Analytics

A typical workflow begins when a recruiter asks:

“Source senior product designers in Lagos with at least five years of SaaS experience and strong systems thinking.”

Jobraker Recruiter then helps the recruiter:

1. Convert the request into a structured sourcing objective.
2. Organize relevant candidates inside the recruiting workspace.
3. Review candidate profiles and fit signals.
4. Compare candidates against the role requirements.
5. Draft personalized outreach.
6. Move qualified candidates through the hiring pipeline.
7. Preserve the resulting context for future recruiter sessions.

The dashboard surfaces live KPIs, top matches, pipeline movement, role activity, and recruiter actions.

DynamoDB supports operational data such as activity events, synchronization jobs, audit records, notifications, and workflow state, while Supabase remains the source of truth for authenticated recruiter data.

The result is not a one-off AI response.

Jobraker Recruiter produces a working recruiting system containing roles, candidates, pipeline stages, analytics, assistant conversations, and recruiting memory that grows with every search.

OpenAI Build Week extension

Jobraker Recruiter existed before OpenAI Build Week, but it was meaningfully extended during the official submission period using Codex and GPT-5.6.

The most important Build Week improvement was changing the AI architecture from a local command-line assumption into a browser-compatible Codex experience.

The application now uses a Codex App Server architecture that allows the Vite web application to communicate with a persistent Codex-backed service instead of asking users to manually run Codex CLI commands from their machines.

This extension was designed to support:

• Connecting a recruiter’s ChatGPT account
• Starting and continuing Codex-powered recruiter conversations
• Sending recruiter tasks from the browser
• Persisting conversation and workspace state through Supabase
• Mapping Codex responses back to roles, candidates, sourcing tasks, and pipeline actions
• Supporting a hosted product experience rather than a local developer-only workflow

GPT-5.6 was used through Codex during the implementation of this extension, particularly for architecture analysis, authentication flow decisions, integration planning, debugging, code restructuring, and validating how the web application should communicate with the Codex runtime.

The Build Week work did not replace the existing recruiting product. It extended the product with a stronger AI execution layer.

How we built it

Jobraker Recruiter is built with:

• React 19
• TypeScript
• Vite
• Tailwind CSS
• Supabase
• Vercel
• AWS DynamoDB
• Supabase Edge Functions
• OpenAI Codex
• GPT-5.6

The product shell combines:

• Landing and authentication
• Recruiter onboarding
• Dashboard
• Candidate management
• Candidate sourcing
• Pipeline management
• Role management
• Analytics
• Settings
• Profile-aware workspace logic
• Codex-powered assistant interactions

Core application architecture

Supabase provides:

• Authentication
• User profiles
• Recruiter workspaces
• Candidate and role data
• Assistant conversation state
• Row-level security
• Persistent application records

AWS DynamoDB provides a complementary operational data layer for:

• Recruiter activity streams
• Dashboard events
• Synchronization checkpoints
• Background workflow state
• Audit records
• Notification state
• Fast key-value workflow records

The web application is deployed through Vercel.

Codex architecture

The Build Week extension separates the browser interface from the Codex runtime.

The architecture is:

Vite web application → Supabase authentication and persistence → hosted Codex App Server → Codex and GPT-5.6

This approach prevents the browser application from depending on a locally installed Codex CLI process.

The recruiter interacts with Codex through the Jobraker interface, while the application manages authentication, conversation identity, workspace context, and saved results.

The Codex-powered workflow follows a bounded loop:

recruiter goal → structured assistant request → Codex reasoning and execution → saved workspace result → recruiter review → refinement → next action

The goal was not to place a generic chatbot inside an applicant tracking system.

The goal was to connect an AI coding and agent runtime to a real recruiting workspace where its output can become visible, editable product state.

AWS DynamoDB integration

The application keeps AWS credentials out of direct browser-to-DynamoDB requests.

Recruiters can configure DynamoDB settings inside the application, but the actual connection is handled through a Supabase Edge Function.

The architecture is:

Vercel web application → Supabase Auth → Supabase Edge Function → AWS DynamoDB

This allows the backend function to securely test and use DynamoDB without exposing AWS credentials to the browser.

The DynamoDB connector supports:

• AWS region
• Table name
• Access key ID
• Secret access key
• Connection testing
• Enable and disable controls
• Connector removal

Recruiter product surface

Jobraker Recruiter gives lean teams a complete operating workspace rather than only a chat interface.

• Dashboard — recruiting overview, recent activity, workspace state, and live performance indicators
• Sourcing — candidate discovery and enrichment workflows
• Candidates — structured candidate profiles, experience, skills, and fit signals
• Pipeline — visual hiring stages for reviewing and progressing candidates
• Roles — open-role management and applicant-quality signals
• Analytics — insights into recruiting activity, candidate movement, and role performance
• Assistant — Codex-powered recruiter conversations connected to workspace context
• Settings — profile management, integrations, and DynamoDB connector configuration

How Codex and GPT-5.6 were used

Codex was used throughout the Build Week development process rather than only for generating isolated code snippets.

It helped with:

• Auditing the existing Jobraker Recruiter architecture
• Identifying assumptions tied to a local Codex CLI workflow
• Designing the transition to Codex App Server
• Planning browser-to-server communication
• Restructuring authentication and session handling
• Connecting assistant conversations to Supabase persistence
• Debugging TypeScript and Vite integration issues
• Reviewing security boundaries
• Refactoring components without recreating the existing interface
• Validating build and runtime behavior
• Documenting the new architecture and testing path

GPT-5.6 was especially useful when the task required reasoning across multiple parts of the application at once.

For example, replacing a local CLI integration affected authentication, browser security, Supabase persistence, backend communication, conversation state, deployment, and the recruiter experience. GPT-5.6 helped reason across those dependencies before Codex implemented and reviewed the changes.

I still made the final product and architecture decisions.

Codex accelerated implementation, surfaced risks, proposed alternatives, and helped test the resulting system, while I decided what matched the product’s goals and existing technical constraints.

Challenges we ran into

Moving Codex from local CLI assumptions to a web product

The largest Build Week challenge was that a Vite application running in a browser cannot safely start or authenticate a local Codex CLI process for every user.

The product needed the functionality of Codex without turning setup into a developer-only experience.

The solution was to introduce a Codex App Server architecture where the browser communicates with a persistent backend service and Supabase manages authenticated application state.

Preserving the existing product

Jobraker Recruiter already contained a complete recruiter interface.

The Build Week work needed to extend the AI architecture without rebuilding the dashboard, candidate pages, pipeline, roles, analytics, or existing design system.

Codex was instructed to reuse the existing components and product structure rather than replace them with newly generated interfaces.

Authentication and session ownership

A recruiter’s Codex conversations need to remain associated with the correct authenticated workspace.

The application therefore has to coordinate:

• Supabase user identity
• ChatGPT or Codex authentication
• Assistant conversation IDs
• Recruiter workspace IDs
• Saved messages
• Role and candidate context
• Server-side execution state

This required careful separation between application authentication and Codex runtime authentication.

Architecture balance

The product uses Supabase, DynamoDB, and Codex for different responsibilities.

Supabase remains the authenticated relational source of truth. DynamoDB handles selected operational workloads. Codex provides the reasoning and execution layer.

The challenge was ensuring that each system had a clear responsibility rather than allowing the architecture to become duplicated or inconsistent.

Security

The browser should not communicate directly with DynamoDB or expose sensitive runtime credentials.

AWS access is routed through Supabase Edge Functions, while Codex communication is routed through the hosted app-server layer.

This keeps sensitive credentials and privileged actions outside the browser.

State across views

Dashboard pages, candidate profiles, roles, pipeline stages, analytics, and assistant conversations all require shared recruiter context.

The application uses Supabase-backed workspace data and coordinated frontend state so that assistant output can become part of the recruiter’s actual workflow.

Accomplishments that we are proud of

• Built a complete web-based recruiter workspace rather than a standalone AI demo
• Added Supabase authentication, profiles, protected routes, and recruiter workspace persistence
• Built product areas for roles, sourcing, candidates, pipeline, analytics, settings, and assistant conversations
• Extended the application from local Codex CLI assumptions to a Codex App Server architecture
• Designed a browser-compatible connection between the Vite application and Codex
• Added persistent assistant and recruiter context through Supabase
• Used Codex and GPT-5.6 to audit, restructure, debug, and validate the Build Week implementation
• Preserved the existing Jobraker Recruiter interface instead of replacing it with generated UI
• Added DynamoDB as a complementary operational data layer
• Created a DynamoDB settings flow with save, test, enable, disable, and remove actions
• Routed DynamoDB access through Supabase Edge Functions
• Kept privileged runtime and cloud credentials outside the browser
• Produced a product where AI output can become editable roles, candidates, outreach, and pipeline state

What we learned

A recruiter does not only need a generated message.

They need a loop:

search → inspect → compare → outreach → schedule → remember → repeat

Jobraker Recruiter applies that principle to hiring.

The assistant must not only answer. It must leave behind editable records, visible pipeline state, saved context, and workflow memory that the recruiter can trust.

We also learned that bringing Codex into a consumer-facing web application requires a different architecture from using Codex locally.

A web product needs:

• Persistent authentication
• Clear session ownership
• Secure backend execution
• Saved conversation state
• Product-specific context
• Structured outputs
• A reliable testing path

The Build Week extension transformed Codex from a local implementation tool into part of the product’s recruiter workflow.

We also learned that Supabase, DynamoDB, and Codex can complement one another when their responsibilities remain clear.

• Supabase is responsible for authentication, relational workspace data, persistence, and row-level security.
• DynamoDB is useful for fast operational records, workflow state, and event-style data.
• Codex provides the reasoning and execution layer that helps recruiters move work forward.

What is next for Jobraker Recruiter

• Expand Codex-powered candidate sourcing and enrichment
• Convert more assistant results directly into structured workspace actions
• Add richer candidate comparison and ranking workflows
• Improve role-aware outreach generation
• Add Gmail and Calendar actions for recruiter communication and scheduling
• Add richer dashboard event history backed by DynamoDB
• Improve team workspace collaboration
• Add deeper analytics for outreach, role performance, and candidate movement
• Strengthen approval controls before Codex performs external recruiter actions
• Add clearer execution logs so recruiters can inspect how an assistant result was produced

Team

Miles — solo builder

Responsibilities:

• Product strategy
• Product design
• AI workflow architecture
• React and Vite implementation
• Supabase integration
• AWS DynamoDB integration
• Codex App Server architecture
• GPT-5.6-assisted engineering
• Recruiter user experience
• Testing
• Documentation
• Demo preparation

Built With

• ai-agents
• applicant-tracking-system
• aws-dynamodb
• codex-app-server
• framer-motion
• gpt-5.6
• lucide-react
• openai-codex
• postgresql
• radix-ui
• react
• react-router
• recharts
• recruiting-automation
• rest-api
• row-level-security
• supabase
• supabase-auth
• supabase-edge-functions
• tailwind-css
• tanstack-query
• typescript
• vercel
• vite
• web