What job postings reveal about the technologies a company is adopting

Job postings reveal the technologies a company is adopting that its website never shows: the data warehouse behind its reporting, the cloud platform under its product, the finance system its accountants work in. This guide shows an analyst or a revenue operations lead how to read a named tool correctly, how to tell a system in use from one on its way in, and how to join the posting view to website detection on one company with a query.

What a job posting reveals about the technologies a company is adopting

A job posting names the software a role will work with, in the employer's own words and on the employer's own careers page. Read across a company's open roles, those names show which systems it runs, which it is bringing in and which teams work in them, including systems that leave no trace on a public website.

In its job openings survey, the US Bureau of Labor Statistics counts a job as open only if it meets three conditions: a specific position exists with work available for it, the job could start within 30 days, and the employer is actively recruiting workers from outside the establishment. Posting a notice on the internet is one of the recruiting steps it lists. A posting is that step made public, so read a tool it names as part of work the employer expects to staff soon.

The tools sit in prose. The schema.org vocabulary gives a job posting a skills property for the knowledge and abilities a role asks for. Google's guide to job posting markup lists five required properties: the date posted, the description, the hiring organisation, the job location and the title. It requires the description to represent the job completely, with responsibilities, qualifications and skills among its parts. So the tools are normally found in the description text, and the catalogue a dataset matches them against decides what you can count.

In Fokals data, Job Postings holds every role a company publishes, labelled by job function, seniority and ten role flags, with the tools named in it. The tools are matched from a curated catalogue of software, and a company's own products are left out of the tools it is taken to use.

Reading hiring data: skills and requirements in job postings as technology adoption signals

A tool listed under the skills or requirements of a job posting becomes a technology adoption signal once you read it in context: how many roles name it, which functions those roles sit in, whether the role builds the system or only uses it, and when the tool first appeared in the company's postings.

Five tests turn a mention into a reading. Each uses a field of Job Postings in the hiring dataset.

A posting records an intention to hire, so every test reads direction. A count of postings is a floor for use: a fully staffed team names nothing.

Applied in order, the tests give a starting rule: the first row that fits wins. Set its thresholds on accounts whose stack you already know.

Using job listings to track a company's tech stack adoption

To track tech stack adoption, turn a company's job listings into a dated series for each tool: the number of open postings that name it each day and the day it was first named. A tool that goes from no postings to several, in roles that build or select it, points to an adoption you can date.

Job Postings (job_postings) has one row for each posting, with the tools it names in technologies, its labels in labels and its dates. Hiring Activity (company_hiring_daily) has one row for each company and day, with the open postings naming each tool in tech_mentions. The first query builds the inventory: every tool a company's postings name, with its counts, job functions, builder roles, adoption flags and dates.

-- Postgres syntax. technologies is the JSON list of tools named in a posting,
-- labels the JSON object of its labels. Load both as jsonb.
select
  p.company_id,
  p.company,
  t.tool,
  count(*) filter (where p.closed_at is null)                        as open_postings_naming,
  count(*)                                                           as postings_naming,
  count(distinct p.labels ->> 'job_function')                        as job_functions,
  count(*) filter (where (p.labels ->> 'technical_depth')::int >= 2) as builder_roles,
  count(*) filter (where p.labels ->> 'new_initiative' = 'true'
                      or p.labels ->> 'selects_tools'  = 'true'
                      or p.labels ->> 'team_build'     = 'true')     as adoption_roles,
  bool_or(p.found_on_first_read)                                     as in_baseline,
  min(p.first_seen_at) filter (where not p.found_on_first_read)      as first_named_opening
from job_postings p
cross join lateral jsonb_array_elements_text(p.technologies) as t(tool)
group by p.company_id, p.company, t.tool
order by p.company_id, open_postings_naming desc;

in_baseline is true when a posting naming the tool was already open when the company's roles were first observed: read the tool as established. first_named_opening dates the first role seen to open. The tool values are the keys of tech_mentions, which the second query takes as a parameter.

-- Open postings naming one tool, day by day, for one company.
select
  day,
  open_postings,
  coalesce((tech_mentions ->> :tool)::int, 0) as naming_tool
from company_hiring_daily
where company_id = :company_id
order by day;

Chart naming_tool beside open_postings. The first day above zero after a run of zeros is the dated first mention, and the ratio of the two columns keeps a hiring surge from passing as a tool surge. Daily tables are written once, after the day closes, and never revised.

Website technology detection vs job postings as technographic data

Website technology detection and job postings are two sources of technographic data that see different parts of a company. Detection reads what a website makes public and dates the arrival and removal of each tool. Postings name the systems staff work in. They overlap on customer-facing tools and complement each other elsewhere.

In Fokals data the two sources are separate datasets on one company ID. Technology Stack, in the marketing stack dataset, holds the technologies detected on each company website with first-seen and last-seen dates, and Technology Changes records every adoption and removal as a dated event. What a Fokals technology row tells you explains each field of a row.

Limitations of website technology detection: Wappalyzer, BuiltWith and the tech stack in job postings

The limitation of website technology detection is its field of view: it reads what a site makes public. Wappalyzer's browser extension and BuiltWith each describe reading a site's pages. The part of a tech stack that never touches a public page, such as a data warehouse or a finance system, shows up in job postings that name it.

Wappalyzer says its browser extension inspects the HTML, scripts, cookies, network requests and certificates of the pages you visit, looking for technology fingerprints. BuiltWith's indexing policy says its system determines a website's technology profile by looking at the publicly visible code, from information anyone could find, and makes no attempt to log in or to reach restricted areas.

That is the strength of the method as much as its edge: the evidence is public and covers every company with a website. A detection shows presence on the website. Hiring signals supply the rest while a company is hiring, and a tool that appears in both sources is confirmed.

Which cloud provider or data warehouse a company uses: what technographic data shows

Technographic data shows the cloud provider or data warehouse a company uses through two kinds of evidence. Website detection shows who hosts and delivers the public site. Job postings name the cloud platform engineers build on and the warehouse analysts query. For the warehouse, postings carry evidence that a website seldom shows.

These systems are common and mostly internal. Eurostat's statistics on cloud computing in enterprises, from a survey of enterprises with at least 10 employees or self-employed persons, report that 52.74% of EU enterprises used paid cloud computing services in 2025. Among those users, 58.16% used cloud software for finance or accounting and 45.52% hosted their database in the cloud. A survey gives the share. Technographic data names the companies.

Job Postings labels the tool families a posting names or requires, among them Snowflake, Databricks, AWS, Azure, Google Cloud, SAP and Workday, so each row of the table is a filter on labels. The query below joins the two views on company_id, one row for each company: Technology Stack (company_technologies) beside the postings.

-- Postgres syntax. One row per company: website view beside posting view.
with site as (
  select
    company_id,
    count(distinct technology)          as technologies_on_website,
    count(distinct technology_category) as website_categories
  from company_technologies
  where missing_since is null
  group by company_id
),
roles as (
  select
    company_id,
    count(*)                                                         as open_postings,
    count(*) filter (where labels ->> 'tool_snowflake' = 'true')     as naming_snowflake,
    count(*) filter (where labels ->> 'tool_snowflake' = 'true'
                       and (labels ->> 'technical_depth')::int >= 2) as snowflake_builders,
    count(*) filter (where labels ->> 'tool_databricks' = 'true')    as naming_databricks,
    count(*) filter (where labels ->> 'tool_aws' = 'true')           as naming_aws,
    count(*) filter (where labels ->> 'tool_azure' = 'true')         as naming_azure,
    count(*) filter (where labels ->> 'tool_gcp' = 'true')           as naming_gcp,
    count(*) filter (where labels ->> 'tool_sap' = 'true')           as naming_sap,
    count(*) filter (where labels ->> 'tool_sap' = 'true'
                       and labels ->> 'new_initiative' = 'true')     as sap_new_initiative
  from job_postings
  where closed_at is null
  group by company_id
)
select
  coalesce(r.company_id, s.company_id) as company_id,
  s.technologies_on_website,
  s.website_categories,
  r.open_postings,
  r.naming_snowflake,
  round(100.0 * r.naming_snowflake / r.open_postings, 1) as snowflake_share_pct,
  r.snowflake_builders,
  r.naming_databricks,
  r.naming_aws,
  r.naming_azure,
  r.naming_gcp,
  r.naming_sap,
  r.sap_new_initiative
from roles r
full join site s on s.company_id = r.company_id;

A company with website columns and empty posting columns has no open roles on record, so the website view is the reading you have. For a tool both sides can see, such as a CRM, finding accounts by the technology they run builds the list from the website side.

Cloud provider and data warehouse detection in technographic data: BuiltWith, 6sense and others

Providers of technographic data differ in the evidence behind a cloud provider or data warehouse record. BuiltWith detects technologies on websites and lists hosting among them. 6sense documents website scans and job postings as sources. TheirStack reports the technologies detected in job postings. Ask each provider which evidence a record rests on.

Three questions settle what such a record means, whoever supplies it.

1. Which evidence does the record rest on, a page, a DNS record or a posting, and can you open it?
2. What do its dates mean: first seen and last seen on a website, or the first and latest posting that named the tool?
3. What happens when the evidence ends: is the record kept after the last posting closes, and for how long?

Run them on companies whose stack you know before comparing providers.

A worked example: Acme Robotics read from both views

Acme Robotics is an invented company, and every figure in this example is illustrative.

Assumptions:

• Acme Robotics has 40 open postings on the day of the query.
• 9 of them name Snowflake. 6 of the 9 have a technical depth of 2 or 3 and 3 have a depth of 1, across four job functions.
• 12 name AWS. 1 names Azure, in a role with none of the adoption flags.
• Snowflake and AWS were named in postings already open when the company's roles were first observed.
• 3 name SAP. All 3 opened in the last 30 days and carry the new-initiative flag, and no earlier posting names SAP.
• 2, in two job functions, name the marketing automation tool that Technology Stack also detects on the website.
• Technology Stack lists 14 technologies on the website, among them analytics, advertising, chat and a content delivery network.

Each share is the count divided by the 40 open roles.

A posting can name several tools, so the counts need not add up to 40. Three readings follow.

• The cloud. The content delivery network on the website says who delivers the public site. The cloud under the product is AWS: 12 roles against 1 for Azure.
• The warehouse. Snowflake is operated in-house, because 6 of the 9 roles that name it, or 66.7%, build or administer systems.
• The dated event. SAP fits the first row of the starting rule. Three new-initiative roles in 30 days, with no earlier mention, date a roll-out.

Timing outreach with hiring signals turns the third reading into a sales play, and reading technology adoption as a signal of vendor revenue counts it across many companies.

How the two views are delivered

Both views arrive on one company ID, by REST API or as bulk files, and the hiring dataset is refreshed daily. Every observation is dated, and the data dictionary defines each field used in the queries above.

Frequently asked questions

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.

What this page says about the products it names was checked against their public documentation on 7 October 2026. Product and company names are trademarks of their owners. Fokals is not affiliated with them or endorsed by them.