Job postings are the earliest buying signal your GTM stack ignores

A company's marketing site tells you what it wants you to believe. Its job postings tell you what is actually true. Nobody writes "experience with Kafka, Snowflake, and dbt required" into a job ad as branding; they write it because a hiring manager needs someone who can operate the stack they really run. That makes job postings one of the best technographic and intent data sources available, and it is almost entirely ignored by the standard GTM stack.

This post covers what you can extract from hiring data, where the extraction goes wrong, and how to build a pipeline for it.

What a job post leaks

The current stack. Requirements sections enumerate the production stack more honestly than any tech-detection crawler. Website-based technographics tools (BuiltWith, Wappalyzer, and their alternatives) see what ships to the browser: the analytics snippet, the framework, the CDN. They cannot see Datadog, Terraform, Snowflake, Airflow, or anything else that lives behind the firewall. Job posts name those tools constantly.

The next stack. "Nice to have" sections and phrases like "help us migrate to" leak roadmaps. A company posting three roles mentioning Kubernetes when its current infra jobs say ECS is telling you about a migration before any analyst report does.

Initiatives before announcements. The first "Head of AI" posting, the first security engineer, the first hire in a new country. Each is a strategic decision that became public the moment someone needed to staff it.

Timing. This is the part sales teams care about. Content-based intent providers (Bombora, 6sense, ZoomInfo) detect an account researching a category, which happens when the evaluation is already underway. Hiring for a role that will use your product happens earlier: the budget exists, the initiative is committed, and the person who will run the evaluation has not been hired yet. Hiring signals typically fire one to two quarters before content intent lights up on the same account.

Where naive extraction goes wrong

If you grep descriptions for tool names, you will poison your data in three ways I know from experience:

• Negation and direction. "Migrating away from Oracle" is a churn signal for Oracle and a buy signal for its competitors. A keyword match reads it as Oracle usage. You need at least phrase-level context around every hit.
• Ambiguous tokens. "Go", "R", "Ray", "Spring", "Flow". Short names need co-occurrence rules ("Go" plus "goroutines" or "Golang") or you will conclude that every logistics company runs Golang because their ads say "go the extra mile".
• Comparison mentions. "Experience with Datadog or similar observability tools" confirms the category, not the vendor. Treat "or similar" and "such as" lists as category-level evidence, weaker than a bare "we use Datadog".

The unit of belief should be company-level with decay, not posting-level: a tool mentioned across five postings over six months is stack; a tool mentioned once in one ad might be one manager's wishlist.

Building the pipeline

You need two inputs: a stream of job postings you can filter by description text, and a way to check the visible web stack of the same companies so the two signals corroborate each other.

For the postings side, I work on JobsPipe, which aggregates 30+ ATS feeds and job boards into one normalized search endpoint. Finding every company that posted a job mentioning your target technology in the last two weeks is one call:

curl -X POST "https://api.jobspipe.dev/v1/jobs/search" \
  -H "Authorization: Bearer jp_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "description_or": ["Kubernetes", "EKS", "GKE"],
    "posted_at_max_age_days": 14,
    "include_total_results": true,
    "limit": 50
  }'

Each result is a normalized posting with company, job_title, country_code, date_posted, and final_url, so the output drops straight into an enrichment table keyed by company.

For the website side, the same API has a stack scanner that fetches a domain and returns detected technologies:

curl -X POST "https://api.jobspipe.dev/v1/stack/scan" \
  -H "Authorization: Bearer jp_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "stripe.com"}'

The interesting analysis lives in the difference between the two views. A company whose website scan shows Segment while its job posts mention Snowflake and dbt has a modern data stack that no page-source crawler would ever report. A company hiring "our first data engineer" with no warehouse mentioned anywhere is a greenfield account for every vendor in that category.

A concrete scoring sketch

For a vendor selling, say, observability tooling, a workable v1 score per account:

• Category hire in the last 90 days (SRE, platform engineer, DevOps): strong, this person will run the evaluation.
• Competitor named in "we use" context: medium, displacement play with a known incumbent.
• Competitor named in "or similar" context: weak, category confirmed, vendor open.
• Stack scan shows the category is absent from their visible tooling: greenfield modifier.
• Three or more engineering postings in 30 days: growth modifier, budget is moving.

None of this needs ML to start. It needs clean, deduplicated, fresh postings data with searchable descriptions, which is the part that is genuinely painful to build yourself (I wrote up the per-ATS details in a separate post on public ATS feeds).

JobsPipe has a free tier at jobspipe.dev (100 requests/month), docs here, and an open-source CLI if you want to pipe results into a spreadsheet before writing any code. If you are building sales-intel, recruiting tools, or market research on top of hiring data, I would genuinely like to hear what signals you wish existed.