TheirStack vs Coresignal

A hiring signal decays in days — the value is reaching out while the need is fresh and before the company runs a formal process.

The unit of outreach is the company, not the posting — "companies hiring SDRs" has to be one query, not a jobs export you post-process into accounts.

The people running this motion are sales, not engineers — they need to build, refine, and export the list themselves.

A large share of postings are placed by staffing agencies on behalf of unnamed clients — outreach to the intermediary is a wasted touch, so the provider must classify company type and let you filter on it.

A hiring signal points at a company, but the email goes to a person — native contacts save a second tool, though most teams already run waterfall enrichment downstream.

Outreach on autopilot means new matching companies flow into the CRM or sequencer as they appear, without anyone re-running the search.

The team running this has no engineer to receive a webhook — a saved search that fires an email or Slack alert on new matches is what autopilot looks like without code.

The same query runs forever — without suppressing companies already exported, already in the CRM, or already sequenced, the motion re-bills and re-emails the same accounts every week.

Half of this motion is watching a named account list — past customers, open opportunities, a territory — which means pulling jobs for your list of companies, not just discovering new ones.

A seller whose ICP is DACH or LATAM rejects a US-centric provider outright — what matters is depth in your target countries and languages, not global totals.

The posting says what the company needs; the reply rate depends on writing to the person who owns that pain — mapping each posting to its hiring manager beats guessing from a title list.

The signal is only as complete as the sources behind it — a segment of the market the provider does not scrape is an in-market account that never enters the list.

The matching companies still have to be qualified — size, industry, and country decide who actually gets outreach.

Reaching out about a role filled last month burns the rep's credibility — sequences must stop when the role closes, and "just filled the role" is itself a trigger.

In an automated pipeline the same role posted on three boards is three triggers and three emails to the same account — duplicates cause visible outreach mistakes, not just inflated lists.

Bounces and complaints burn the sending domain the whole motion depends on — the data behind the outreach needs a documented lawful basis, especially for EU and California prospects.

The way to judge a signal vendor is to run your ICP and check the matches against accounts you already know — free counts and sample records make that test possible before any money moves.

The buyer is a sales team with a tool budget, not procurement — public self-serve pricing means the motion starts this week, while quote-only annual contracts price out most of the teams that run it.

The posting is the evidence behind the signal — a rep personalizing the first line needs to read the actual job ad, and a link to the source posting beats a black-box "this account is hiring" flag.

The team running this has no engineer to debug a query that returns nothing, so the practical question is whether a non-technical user can get an answer the same day instead of filing a ticket into silence.

The rep asks the assistant for the list instead of building a query — an official MCP server is what makes “which companies started hiring SDRs this week” answerable without opening the tool.

You start from the accounts you already own — the provider must resolve your identifiers (domain, name, LinkedIn URL) to its records, and its match rate on your list is the ceiling of the whole project.

A CRM field is only trustworthy if it refreshes itself — the provider has to deliver updates on a cadence you set, not wait for you to re-run searches.

Filters like title, date, and country scope the pull to the roles that matter for scoring — without them you pay for every posting an account has.

New and closed jobs for your accounts should arrive as webhook events — keeping CRM fields current without a polling pipeline you build and babysit.

A recurring sync re-visits the same accounts every run — unless you can pull and pay for only what changed since last time, the bill scales with cadence times account count instead of with actual hiring activity.

Without removal signals roles never leave the CRM and hiring-activity counts only ever go up — reps end up acting on positions filled months ago.

An enrichment run touches thousands of accounts — it should be a few synchronous batched requests, not an async submit-wait-download-unzip loop.

The field says what the account is hiring for now — stale data misleads every rep who reads it.

Hiring-activity counts drive scoring — the same posting counted once per source inflates every score.

Coverage on the homepage is not coverage on your accounts — running your own list and seeing how many return data must cost nothing, both to evaluate before buying and to skip paid pulls for accounts with nothing new.

This use case is the API — the enrichment pipeline is code a developer maintains forever, and the docs decide how long the integration takes.

Fill rate is capped by where your accounts are — a provider deep only in the US leaves the hiring fields of an EMEA or LATAM account list blank, whatever its global totals say.

The sync re-bills every month forever — the real unit is cost per enriched account, which depends on published per-record prices and on whether no-match lookups burn credits too.

A refresh sweeps thousands of accounts in one run — the per-minute cap decides whether that takes minutes or days, so limits must be documented and raisable before the pipeline is designed around them.

The sync is unattended code running on a schedule — an unannounced breaking change upstream silently stops the refresh, so versioned endpoints and a deprecation window are part of the contract.

The enrichment writes vendor data into your CRM permanently — the provider's lawful sourcing becomes your compliance answer when legal or a customer audit asks where the field came from.

Enrichment is increasingly a step inside an agent workflow rather than a nightly job — an MCP server means the agent can fetch what it needs mid-run without a service someone maintains around it.

Enrichment fails quietly — a match rate that drops or a field that starts arriving empty looks like the data, not like a bug. Getting to someone who can check the record is what turns a suspicion into a fix.

A job board competes on having new postings first — every hour between a job going live at the source and appearing on your board is a gap where faster-fed boards already list it. New postings should appear within minutes; daily is the minimum.

The apply button must send candidates to the authentic careers-page posting — not to LinkedIn or another job board, which compete with you for the same candidates and would capture your audience. Broken redirect chains get blamed on your board, not on the source.

Descriptions arrive as HTML fragments, broken encodings, and converted PDFs. Unless the provider normalizes them into one format, every listing renders differently on your board.

You pay per record and your users see every record — a duplicate is both a bill you did not need and a repeated listing.

Stale listings destroy candidate trust and search rankings — the provider must know whether each posting is still active or already expired, and tell you when it closes so you can delist it.

A job board displays every purchased record to the public — if the license does not permit republishing, the entire board is a violation waiting for a takedown letter.

Without push delivery, keeping the board current means re-querying the API on a schedule, diffing the results against what you already list, and monitoring that pipeline forever. With webhooks the provider notifies your endpoint the moment a matching job is posted or closed, so listings appear and get delisted on time with far less code.

A board launches empty — the initial backfill needs thousands of currently-active matching jobs on day one as a bulk load, not paged through a per-request metered API.

Most boards are country- or region-niche — a global source count says nothing about whether the provider actually covers your market in its local language.

You pay per record forever — whether the price is public and what silently re-bills (duplicates, expiry re-checks, refreshed records) decides the real monthly cost, not the headline rate.

Coverage varies wildly by niche — the only way to know whether a provider can actually fill your board is to count and sample the currently-active jobs matching your filters before paying, and again whenever you weigh adding a category.

Your board republishes the scraped content under your own domain — the provider's sourcing practices become your public legal exposure, not just theirs.

Inventory breadth is the whole point of backfilling — coverage of career pages and ATS boards, not just the big aggregators, decides how many niches you can serve.

Staffing agencies flood popular niches with anonymous-client reposts of the same role — without a company-type classification to filter on, agency spam crowds out the direct-employer listings candidates came for.

A UI over the full inventory lets you run your board's exact filters and see every matching job before writing integration code — validating coverage for your niche, and letting the non-engineers deciding what the board carries explore the data themselves.

Logo, domain, and headcount turn a bare listing into a page worth indexing, and enable company profile pages.

A niche board needs tight filters — 500 relevant jobs beat 50,000 random ones.

Salary, employment type, and location power both the faceted search candidates expect and the Google JobPosting structured data behind the board's main SEO traffic channel.

A backfill is an integration project — how fast an engineer gets from the docs to the first working request is real cost.

A board ingests the whole feed repeatedly rather than querying it, so the file format decides whether the loader is a warehouse COPY or a conversion script maintained forever.

A board is a production dependency: a feed that stops or starts shipping malformed records is visible on your site within hours, and the response time you can expect decides how long it stays broken.

The list is only as long as the company ↔ technology signals behind it — thin coverage means missing most of your addressable market.

You are targeting users of a named technology — that only works against a maintained catalogue you can filter by, not free-text extraction you have to guess at.

Building and exporting a campaign list is a GTM task — it cannot depend on engineering time.

Backend and internal tools — databases, ERPs, infrastructure — never appear in website source code, so a provider that only scans frontends cannot build the list at all.

Before paying for the list you will spot-check it — "why do you say company X uses tech Y" must have a verifiable answer, or every false positive becomes a refund dispute.

These are campaign-shaped projects: buy the list once, run the campaign — a recurring subscription is the wrong billing shape.

The raw list still has to be qualified before export — firmographic filters at query time (size, industry, country) decide who actually gets outreach, not fields appended afterwards.

A signal last seen two years ago targets an account that already switched — first- and last-detected dates separate current users from historical ones.

The campaign emails go to people, not domains — a company list without contacts forces a second vendor and a matching step before a single email can be sent.

A one-time buyer has no second month to discover the list is bad — seeing how many companies match and sampling records before paying is the purchase decision.

A campaign list is a project purchase with a project budget — a public per-record or per-list price closes it this week, while quote-only pricing turns a one-time buy into an enterprise sales cycle.

The campaign emails EU and California prospects with data someone scraped — the provider needs a documented lawful basis legal can sign off on, or the list never gets used.

A job posting names the tools the team is staffed to run, including the ones no crawl can see — it is the only surface that reaches the internal stack.

Technology detections are the claims most likely to be disputed by a prospect ("we do not use that"), so a channel that gets a wrong attribution corrected — rather than acknowledged — is what keeps the list trustworthy.

Technographic prospecting is iterative research — “who runs Snowflake but not dbt” is a conversation, and an MCP server lets the rep have it with the assistant instead of with a filter UI.

An enrichment that only fills the field for the largest companies leaves most of a CRM blank.

CRM fields need normalized technology names — free-text extractions cannot be segmented, deduplicated, or reported on.

Tech stacks change — the append is only useful if it re-runs on a cadence without manual work.

The append starts from your records, and CRMs are messy — if the provider only accepts clean domains, every account with just a name or LinkedIn URL comes back unmatched and the field stays blank.

A CRM field reps distrust gets ignored, then ripped out — each detection needs a confidence level and a way to verify why the provider believes it.

The whole point of refreshing is that stacks change — without first- and last-detected dates on each signal, every run re-writes technologies the account may have dropped years ago.

A website-scan-only provider fills the column with frontend widgets and leaves it blank for the databases, ERPs, and internal tools most segmentation actually runs on.

A monthly refresh that re-pays for the unchanged majority of the warehouse is a 10x cost difference versus paying only for deltas.

Above warehouse scale, per-record API credits stop making sense — the append becomes a flat-file load with periodic refreshes at a flat price.

Warehouse-scale appends need batched, synchronous retrieval rather than per-record calls or async file jobs.

This buyer has no UI to fall back on — the append runs as code against the API, and the docs decide how long the integration takes.

The purchase decision is a match test on your own list — vendor-published match rates run far above what real CRM data returns, so sampling coverage before paying is the only honest benchmark.

The real unit is cost per matched record — published prices, and whether no-match lookups bill credits, decide what the append actually costs at CRM scale.

A full-CRM append is tens of thousands of lookups — the per-minute cap decides whether the refresh takes hours or weeks, so limits must be documented and raisable.

The append is unattended code on a schedule — an unannounced breaking change upstream silently stops the refresh, so versioned endpoints and a deprecation window are part of the contract.

Hiring is the only surface that reports the internal stack, and the one that dates a technology to when the company was actively investing in it rather than when a tag was last served.

Once detections are written into the CRM, a systematic error propagates to every team reading them, and unwinding it needs someone at the vendor who can confirm whether the detection logic changed.