How to source candidates without LinkedIn (2026 AI stack)

Why I built a non-LinkedIn sourcing stack

A client we work with hires senior software engineers for high-frequency trading. These are some of the hardest roles to fill: a small known talent pool, candidates who are often not active on LinkedIn, and competitors who watch the same profiles you do.

Two things broke the LinkedIn-default playbook on this engagement.

1. Not every recruiter on the team had a Corporate LinkedIn Recruiter seat. Per-seat pricing made full team coverage a non-starter.
2. The recruiters who did have seats burned email credits on prospects who never replied. InMail caps and the Recruiter UI itself were slowing down work on roles where speed mattered most.

We rebuilt the workflow around Claude and a handful of external data sources. Time-to-shortlist for a new req dropped to about 30 minutes end-to-end, from job brief in to a ranked top-of-funnel out. That number is the bar I now hold the rest of the stack to.

Opinion stake. LinkedIn Recruiter is a great database. It is not a great workflow. Once you stop trying to make it both, the rest of the stack opens up.

The five layers of a sourcing stack

Whatever you replace LinkedIn with, you are still filling these five jobs. The table is the cheat sheet.

Layer	Job	LinkedIn default	What replaces it
Discovery	Find candidates that match the brief	Recruiter search + Projects	People databases (Coresignal, Bright Data, PDL)
Enrichment	Add contact + context	InMail + profile data	ContactOut (primary), Apollo.io (alt), Hunter.io for corporate email
Ranking	Triage to a shortlist	Recruiter notes	Structured scorecard prompts in Claude
Outreach	First touch	InMail	Email + personalised cold messages
Tracking	Pipeline state	Recruiter Projects	ATS or CRM of choice

Below is what we use in each layer and why.

1. Discovery: people databases that aren't LinkedIn

The replacement for "I'll just search LinkedIn" is a people database with API access. Three I'd evaluate first:

• Coresignal. Firmographic and employee data. Strong for building your own searchable index or feeding a downstream pipeline. API or flat-file delivery.
• Bright Data. Public-web datasets as a service. Useful when you need raw, queryable rows or coverage of markets where LinkedIn is thin, such as DACH industrials, parts of APAC, or public sector.
• People Data Labs (PDL). Enrichment-first, but the person dataset works for cold discovery too. Good developer ergonomics.

How to pick:

1. Geographic and role coverage for the niche you actually hire in.
2. Licensing terms. Internal use only? Can you resell or display data to clients?
3. Freshness. When was that "Director of Engineering" title last verified?
4. Minimums. Many vendors gate API access behind a monthly commitment. Make sure the floor matches your volume.

For the HFT engagement we used Coresignal as the index and pulled rows by employer history, location, and a short list of stack signals: specific languages (KDB+, C++, Rust), exchange names, and market-data vendors that show up on real resumes. That alone gave us a long-list of around 400 names for a typical req before any enrichment work.

Beyond paid databases, GitHub, conference attendee lists, podcast guest archives, and public registers (Companies House, Handelsregister, arXiv) all earn their place when you know what you are looking for. They are slower per candidate, but they surface people the commercial databases miss.

2. Enrichment: personal email beats corporate

In recruiting you want a personal email for first-touch, not a corporate one. Three reasons:

• Candidates check personal email outside work hours.
• Corporate spam filters increasingly block cold outreach to work addresses.
• Sending to a corporate inbox risks tipping off the candidate's current employer.

That single choice changes which tool you reach for.

Job	Tool	Why
Verified personal email for a candidate	ContactOut	Reveals personal alongside work email, supports bulk and browser-extension modes
Best-guess corporate email from name + domain	Hunter.io	Pattern-matching against domain conventions is more accurate than letting an LLM guess
Phone, work history, company context	Apollo.io	Reliable fallback when ContactOut misses, plus useful firmographic data

A failed experiment, for the record. Early in this project I tested whether Claude could guess emails directly from a name and a company domain. On a 50-row sample, 30 of 50 bounced, about 60%. The fix was not a smarter prompt. The fix was using the right tool for the job: Hunter.io for corporate patterns, ContactOut for personal addresses.

Lesson worth keeping: LLMs are bad at facts they have no way to verify. Outsource that work.

3. Ranking: an ICP-aware Claude skill

This is where the workflow becomes Claude-native. We built a Claude skill that does four things in sequence.

1. Reads the job description from the client.
2. Extracts the Ideal Candidate Profile (ICP): must-haves, nice-to-haves, deal-breakers, and the signal phrases that map to real experience.
3. Drafts a sourcing strategy: which databases to query, which Boolean strings to run, which adjacent companies to look at.
4. Calls the external database API (Coresignal in our case), pulls candidates, scores each one against the ICP, and returns a ranked shortlist with one-line rationales.

What the recruiter sees is a 10-row table: name, current role, why ranked, the one or two ICP gaps, and a confidence score. The recruiter spends their time deciding who to contact, not on building the long-list.

A trimmed version of the ranking prompt looks like this:

System: You score candidates against an Ideal Candidate Profile (ICP).
Return strict JSON. Never invent attributes that are not in the input row.

Input:
- ICP (must-haves, nice-to-haves, deal-breakers)
- Candidate row (employer history, titles, public bio, GitHub if present)

Output (JSON):
{
  "score": 0-100,
  "must_haves_met": [...],
  "must_haves_missing": [...],
  "nice_to_haves_met": [...],
  "deal_breakers_present": [...],
  "one_line_rationale": "..."
}

Calibrate before you trust it. Run the prompt on 10 candidates you already know the answer for (5 strong, 5 weak). If the scores do not match your gut, the ICP is wrong, not the model.

4. Outreach: the difference between sloppy and signal

The same candidate, two first-touch emails.

Sloppy (what most generic AI tools produce):

"Hi Anna, I came across your profile and was impressed by your background. We have an exciting opportunity that I think would be a great fit for someone of your calibre. Would you be open to a quick chat?"

Signal (what we actually send):

"Hi Anna, saw your KDB+ work on the low-latency book builder at [Firm]. We're hiring a senior dev for a similar role on a US-equities desk, 3-day office split, [salary range] EUR. Open to 15 minutes this week?"

The signal version needs three inputs the recruiter has to provide: role angle, why this candidate (one verifiable detail), and one piece of substance the candidate cares about (salary range, comp model, team size, remote split). Without those, AI cannot help you. With them, the Claude prompt is short and the output rarely needs more than light editing.

5. Tracking: keep it boring

Recruiter-accepted candidates get pushed into the team's existing ATS or CRM. There is no AI here, and there should not be. The pipeline state of record needs to be boring, queryable, and auditable for the hiring manager.

Honest limits

• GDPR. The usual lawful basis for cold recruiting outreach is Article 6(1)(f) legitimate interest. Document the balancing test, keep retention short, honour opt-outs on the first reply. Personal email carries stronger consent expectations than corporate; treat it accordingly.
• Bias. A ranking prompt inherits whatever bias is in your ICP. Audit the ICP for proxy criteria (university tier, employer prestige, gendered language) before you let Claude score 400 people against it.
• Data freshness. Enrichment rows go stale faster than you think. A 90-day-old export is already lying to you about ~10-15% of titles. Re-pull before any volume send.
• Hallucination. Tell the model what is in the input row and tell it not to invent attributes. Same rule that applies to screening applies to sourcing; see the glossary entry on hallucination.

The 30-minute version (do this on a real req tonight)

1. Paste the job description into Claude. Ask for the ICP as a structured list (must-haves, nice-to-haves, deal-breakers).
2. Pick one database you have access to. If you have none yet, start with Hunter.io plus a focused Google site:github.com search to prove the workflow on a small sample.
3. Pull 50 candidate rows matching the ICP must-haves.
4. Run the ranking prompt above. Eyeball the top 10.
5. Enrich the top 10 with ContactOut (or Hunter for corporate where personal is missing).
6. Send 5 personalised first-touches built from the signal-style template. Send the first round manually, automate only after replies validate the angle.

If it takes you 90 minutes the first time, that is normal. The HFT engagement got to 30 minutes after about six iterations and one good Claude skill in the middle.

Where this goes next

The full version of this workflow — the Claude skill, the nightly automation, the database integration, the outreach prompts — lives inside the AI Sourcing Lab. That's where you get the downloadable skill files, the per-tool walkthroughs (Coresignal, Bright Data, ContactOut, Apollo, Hunter, Claude), and the Live Build replays where I rebuild this exact pipeline on real roles.

If you want the broader picture — sourcing plus screening, outreach, recruiter automation, and the Recruiting Systems Builds we ship done-for-you — start at Recruiting OS. The Sourcing Lab is the first Lab inside it; more Labs ship on a continuous cadence.

Either way: stop trying to make LinkedIn Recruiter do work it was never designed for.

For the role-by-role view of how this fits a sourcer's week, see the AI guide for sourcers.