Workflow software · Live
Intern Hunt CRM
A private recruiting pipeline for applications, follow-ups, and interview milestones.
A Supabase-backed job-search workspace for managing opportunities, recruiter context, deadlines, activity history, and pipeline analytics.
- Role
- Product direction, workflow modeling, Supabase data design, interface design, analytics, and testing.
- Year
- 2026
- Status
- Live
- Stack
- React · TypeScript · Supabase · PostgreSQL · TanStack Query · Tailwind CSS · Recharts · Vitest
Overview
Intern Hunt CRM is a database-backed recruiting workspace for managing internship and job applications from initial sourcing through interviews and decisions.
Problem
Job searches become fragmented across spreadsheets, bookmarks, email, calendars, résumé files, and notes.
Solution
The CRM combines opportunity records, recruiter details, follow-ups, deadlines, materials, milestones, activity history, and pipeline analytics in one user-owned workspace.
Feature evidence
Pipeline records
Applications include stage, priority, work mode, recruiter context, and material references.
Follow-through
Follow-ups, deadlines, milestones, and derived activity history keep next actions visible.
Smart views
Search, filters, sorting, and dashboard analytics reveal the state of a personal pipeline.
Activity generation
Meaningful application changes produce a structured history for later review.
System layers
React and TanStack Query consume a repository abstraction that can target live Supabase data or a local sample workspace. Identity and mode participate in cache keys.
- 01
React client
Pipeline, smart views, detail forms, and analytics.
- 02
Query + repository
Mode-aware caching and live or sample data adapters.
- 03
Supabase
Authentication and user-scoped data operations.
- 04
PostgreSQL + RLS
Applications and activity records protected by ownership policies.
Where the engineering concentrates.
Preserving unsaved work
Live data refreshes do not discard in-progress form edits.
Separating live and sample identity
User mode and identity are part of every relevant query key and repository operation.
Choices and tradeoffs.
Repository abstraction
Live Supabase and local sample data expose the same workflow surface.
Explicit scoped queries
RLS is reinforced by user-scoped access patterns.
Derived activity events
Structured history is produced from meaningful state changes.
Client-side analytics
Aggregation remains appropriate for current personal dataset sizes.
Security, accessibility, and testing.
Security
- Supabase authentication
- PostgreSQL Row Level Security
- Explicit user-scoped queries
- Identity-aware query caching
Accessibility
- Labeled forms and validation relationships
- Keyboard-operable search, filters, and sorting
- Text summaries for pipeline analytics
- Responsive application detail views
Testing
- Form validation and application-field mapping
- Recruiting-stage date ordering
- Smart views, search, sorting, and filters
- Pipeline analytics calculations
- Activity generation from meaningful changes
- Preservation of unsaved edits during data refresh
Current boundaries
The current product has a deliberate scope. These boundaries define what it does not claim.
- No custom backend
- No automated email reminders
- Contacts are fields attached to applications
- No drag-and-drop pipeline
- Activity creation is not transactionally coupled to application mutation
- No server-side pagination
- No E2E suite unless later added
The next credible steps.
- 01Create transactional activity writes at a trusted server boundary
- 02Add pagination if a personal pipeline outgrows client aggregation
- 03Add focused end-to-end coverage for critical mutations
What the implementation clarified.
- 01
Stage and date ordering rules belong in reusable workflow logic so forms and analytics share the same assumptions.
- 02
Identity-aware query keys prevent private and alternate data modes from sharing stale cached records.
- 03
Preserving dirty form fields during refresh separates server freshness from ownership of in-progress user edits.