Regular development — Gigantes Group

How a recruiting firm stopped paying twice for people it already knew.

Gigantes Group is a global executive search firm hiring into infrastructure, building services, renewable energy and infratech, across the US, Singapore, Japan and Asia-Pacific. A lean team of recruiters carries a high volume of mandates, so speed to shortlist is close to revenue itself.

The problem

The firm was paying to rediscover its own candidates.

Years of operation had put thousands of candidate profiles into RecruitCRM. When a new mandate came in, the recruiters went to LinkedIn and enrichment tools anyway and paid to find people the firm already knew.

It wasn't laziness. It was that the search doesn't work. A candidate entered as Head of Manufacturing Operations never surfaces for a VP of Plant Engineering mandate, because the words are different even though the person is the same. The firm was buying back its own history, one lookup at a time.

The firm was also calling after the job was posted. A company planning to hire a VP of Engineering doesn't start on LinkedIn — the signal comes weeks earlier, with a funding round, a new facility, a leadership change. By the time the role is public, five other firms have pitched.

What I built

Three modules that compose into one motion, integrated into the CRM and LinkedIn workflow the desk already used. I designed and shipped all of it as their CTO.

1. The Ranker — search by meaning instead of by keyword

A recruiter pastes a job description. I convert the whole brief into a 1,536-dimension vector and query a single unified candidate pool by cosine similarity, returning a leaderboard ordered by fit — up to 500 candidates, at whatever depth the recruiter asks for.

Two streams feed that one pool: a harvester that finds talent the firm doesn't own yet, and a CRM sync that continuously indexes every existing RecruitCRM candidate into the same vector store. Every result is source-tagged. [CRM] means the firm already owns that person and can open them at no cost. [WEB] means newly found.

What changed: the CRM stopped being a filing cabinet. Mandates that used to return zero existing matches now surface ranked people the firm already had, and every one of them is openable at no additional cost.

2. The Harvester — where the precision actually lives

This is the part that looks simple from outside and isn't. Finding LinkedIn profiles that match a search term is easy. Finding the right ones, at a volume a recruiter can work through, is a filtering problem — and it is where most of the engineering went: a query built so its segments AND together as phrases rather than leaking the separator to Google as a minus operator, a bidirectional word-boundary match that recovers candidates whose company name Google truncated, and five filters in a deliberate order.

And it fails closed on purpose. A false positive wastes a recruiter's afternoon; a false negative costs one more search. Given that choice, I built it to be sure rather than generous.

3. The Scout — intelligence before the requisition

The Scout watches the market continuously and scores what it finds 1–10 by urgency: a new facility at 10, Series B/C/D funding at 9, an executive leadership hire at 8, and down to general market noise at 1–2. Anything scoring 9 or above alerts the desk immediately.

Where this pays: the firm reaches target companies four to eight weeks before a role is posted. The person who calls a VP of Engineering the day after they close a funding round is in a different conversation from the person who calls when the job goes live.

And where I made it stop. It scores, stores and alerts. It does not draft outreach and it does not trigger the harvester on its own. That was a decision, not an unfinished feature — see below.

4. The Sequencer — outreach that ends when it should

Selected candidates enter a multi-step sequence across LinkedIn and email, with AI-drafted messages written per candidate rather than from a shared template. Three decisions carry it: a reply sensor that cancels every remaining step the moment a candidate responds; sends from each recruiter's own mailbox, because they are from a real person; and human-likeness throttling so fifty connection requests don't leave at 09:00:00.

The design decision I'd defend hardest

The market-intelligence module could easily have been automated end to end. It finds a signal, scores it, identifies the company, and could have drafted and sent the outreach without anyone touching it. That's what most people building this would do, and it demos better.

I made it stop instead.

The Scout surfaces a signal and alerts a person. The first message to a company — the one that decides whether there's ever a relationship — is written and sent by a human. Not because the machine couldn't, but because that message is where trust gets made, and trust made by a machine is a demo.

There's an obvious commercial cost to this. The automated version is faster and cheaper to run. The reason the system is still in production and still used is that it doesn't do the one thing that would have made the desk stop trusting it.

Most AI advice is "automate more". The judgement is knowing which step to leave alone.

The engineering that doesn't demo

Four things sit under the features nobody asks about, and they are the reason the system runs unattended: rate limiting and an action log on every automated LinkedIn action; a dead-letter queue so a failed enrichment is a row you can retry rather than a silent hole; per-provider cost tracking with alerting, because metered APIs produce invoices, not just bugs; and a written handover checklist for the team that owns this after me.

What this is not

Colossus is not a mass-market product and not a blunt automation tool. It's built for one firm's workflow, where timing and professional reputation are the competitive advantage. Every sequence has a brake. Every enrichment call has a tracked cost. Every match shows its source. The system amplifies recruiter judgement rather than replacing it.

Stack

SvelteKit 2 / Svelte 5 · AWS Lambda via SST v3
Supabase Postgres with pgvector · OpenAI text-embedding-3-small
Inngest for durable workflows · Unipile for LinkedIn
ZoomInfo for enrichment · Serper for market intelligence
RecruitCRM via a typed client · per-recruiter Gmail OAuth

If you're deciding whether to build this yourself, start here. jared@jaredgoldman.dev