AI Skill Report Card
Architecting AI Job Search Engines
Quick Start14 / 15
When someone describes a "smart matching/automation app" idea (job search, recruiting, deal sourcing, candidate sourcing, lead gen, etc.), immediately reframe it using this funnel template and ask what the user profile inputs and source types are — don't let the conversation stay at "find X with AI."
INPUT (user profile / criteria)
↓
CLASSIFICATION (what kind of X is this? → determines sources/rules)
↓
SOURCE ROUTER (pulls from the right sources for this classification, not a fixed list)
↓
CHEAP DISCOVERY (broad candidate set, ~150-200)
↓
FAST FILTERING / hard eligibility rules (→ ~100 qualified)
↓
CRITICAL VERIFICATION (flag facts as VERIFIED/LIKELY/UNKNOWN, never invent data)
↓
AI PRIORITIZATION (score + tiering, e.g. P1/P2/P3, Top 20)
↓
EXPENSIVE AI PERSONALIZATION (only for the top tier: assets, outreach, packages)
↓
TRACKING / FOLLOW-UP LOOP
State explicitly: never run the full candidate set through the most expensive AI model. Cost control is a first-class architecture decision, not an afterthought — it's what makes the product viable at scale for many users.
Recommendation▾
Add a second concrete example with a fuller input/output pair showing actual code, schema, or diagram output rather than bullet summaries
Workflow14 / 15
Progress:
- Step 1: Extract the domain-agnostic core loop (Discover → Qualify → Prioritize → Personalize → Track/Follow-up → Outcome)
- Step 2: Define the User Profile schema as structured inputs, not hardcoded assumptions (e.g. target roles, location, work authorization, languages, compensation, remote preference, skills, seniority, industries, culture/exclusions)
- Step 3: Design the Classification + Source Router layer so sources/filters/personas change per user segment automatically — reject any fixed, one-size-fits-all source list
- Step 4: Design the cost funnel explicitly (cheap discovery → fast filtering → critical verification → expensive personalization), stating approximate volume drop-offs at each stage
- Step 5: Enforce a data-integrity rule for any inferred/uncertain fact (compensation, seniority, etc.): label as VERIFIED / LIKELY / UNKNOWN — never fabricate specifics
- Step 6: Decide which downstream "assets" or outputs are role/segment-dependent (e.g. CV vs. portfolio vs. publications vs. certifications) and let the engine choose the asset mix, not a hardcoded template
- Step 7: Separate Core IP (matching logic, ranking, orchestration, user history/learning loop) from Partner/ISV Capabilities (voice AI, assessments, enrichment, specialized integrations) — build the former, integrate the latter
- Step 8: Propose a minimal, boring tech stack: web framework + managed Postgres/Auth/Storage + background worker/queue for long-running tasks + a multi-model AI router (cheap model for screening, strong model only for high-value personalization)
- Step 9: For any communication channel (email, messaging), design a normalized connector layer (e.g. Gmail/Outlook → normalized object → CRM) so the product isn't locked to one provider; default to read+draft before enabling auto-send
- Step 10: Extend the core loop forward into adjacent value stages if relevant (e.g. interview prep/coaching, negotiation) framed as additional modules using data already collected, ideally via partner APIs
Recommendation▾
Description is somewhat narrow in name ('job search engines') vs. broader stated scope (recruiting, deal sourcing, lead gen) — consider renaming for clarity or tightening description scope
Examples14 / 20
Example 1: Input: "I want to build an app where AI finds job candidates/companies for me and applies automatically." Output:
- Reframe as a 5-stage pipeline: Discovery → Qualification → Prioritization → People (contacts) → Application Package.
- Specify volume drop-offs: ~150-200 candidates → ~100 qualified → Top 20 → few get full expensive personalization.
- Flag that compensation/company data must be tagged VERIFIED/LIKELY/UNKNOWN.
- Recommend Next.js + TypeScript, Supabase (Postgres/Auth/Storage/RLS), background worker for research/enrichment/doc generation, multi-model AI router.
- Explicitly warn against hardcoding this to one profession — design User Profile + Source Router as the abstraction layer instead.
Example 2: Input: "Should we build interview prep as a feature ourselves?" Output:
- Classify it as an adjacent module, not core MVP scope.
- Recommend building the orchestration (trigger after apply/interview booked, feed in CV+JD+company research) as Core IP.
- Recommend sourcing the actual capability (realtime voice AI, assessment engines, coding environments) via partner/ISV APIs rather than building from scratch.
- Note the feedback loop: post-interview, users report actual questions asked; aggregate anonymized data improves future prep for the same company/role.
Recommendation▾
Include a bad-example contrast (e.g. a hardcoded, segment-specific architecture) alongside the good one to sharpen the do/don't distinction
Best Practices
- Always push back on segment-specific hardcoding ("DACH SDR job finder") in favor of profile-driven, classification-based routing that generalizes to any profession/domain.
- Make the cost funnel a named, explicit diagram in every proposal — cheap→expensive staging is the mechanism that makes the product scale economically.
- Treat data honesty as non-negotiable: any uncertain fact gets a confidence label instead of being presented as ground truth.
- Default new integrations (email, calendar, messaging) to read + draft, not autonomous send — reduce risk, add automation later once trust is established.
- Draw a hard line between Core IP (matching/ranking/orchestration/proprietary history) and Partner Capabilities (voice, assessments, enrichment) early in architecture discussions — this determines build-vs-buy decisions and moat.
- Keep the tech recommendation boring and standard for MVP speed: managed Postgres/Auth (e.g. Supabase), a mainstream web framework, background job queue for anything long-running, and a model router abstraction rather than a single hardcoded LLM call.
- Frame the product ambition correctly: it's not "AI finds X," it's "AI builds a personalized discovery-to-outcome engine for each user" — the specific use case (job search) is the first test dataset, not the whole product.
Common Pitfalls
- Do not let a single real use case (e.g. the founder's own job search) silently become the hardcoded product logic — always abstract it back into profile fields and router rules.
- Do not run the entire discovery-stage volume through the most expensive AI model; this breaks unit economics at scale.
- Do not fabricate specific numbers (salary, company size, etc.) when data is uncertain — always mark confidence level instead.
- Do not enable automatic sending of outreach/emails in early versions — read/draft first.
- Do not treat personalization assets as one-size-fits-all (e.g. always generating a "one-pager") — the asset mix should be chosen based on role/domain (portfolio, publications, certifications, GitHub, etc.).
- Do not build every capability in-house by default — check whether a partner/ISV API covers it before writing custom code for non-core functionality.