The sources, by reliability
The evidence for a company technology stack is public but uneven. Ranked by how much weight a finding deserves:
- Job postings. The most reliable single source. A company hiring for a named technology is using it, is committing to it, and the posting is dated.
- Public code repositories. Direct evidence for anything they build openly, and silent about everything they do not.
- Product documentation and developer pages. Reliable for anything customer-facing.
- Engineering writing and conference talks. Rich, but often describes an aspiration or a prototype rather than production.
- DNS and vendor records. Reliable for infrastructure-level services, blind to everything internal.
- Front-end detection. Sees what runs in a browser and nothing else. Frequently mistaken for a full stack picture.
What a detected technology does not tell you
It does not tell you scale, satisfaction, contract value, renewal date or whether the company is happy. A tool appearing once in one posting and a tool the whole engineering organisation is hired around look identical in most detection data.
The useful discipline is to weight by repetition and recency. One mention of a database in one posting is weak. Six postings across two quarters naming the same stack is a commitment.
Migrations are the signal, not the inventory
A static list of what a company uses is mildly useful for qualification. A change in that list is what creates an opportunity. A company that begins hiring for a technology it never mentioned before is migrating, and migrations create budget, deadlines and adjacent purchases.
Detecting that requires a history. A single snapshot cannot tell you what is new, which is why point-in-time technology lookups feel less useful than they sound.
What people actually do with it
Four uses account for most of the value, and each one wants the evidence read differently.
- Qualification. Does this account run the things our product needs to sit next to? A single reliable detection is enough to keep an account in or take it out.
- Displacement. Which accounts run the competitor we replace? Here repetition matters, because a competitor named in one posting may be a pilot and a competitor named in twelve is a commitment.
- Integration and partnership mapping. Which tools do our customers already run, and which of them keep an integration page? Documentation is the source that pays here, not hiring.
- Product evidence. Which technologies are appearing across a market this quarter that were not there last quarter? This one needs history and a fixed watch list, or it becomes anecdote.
How to read it without over-reading it
Three habits separate a technology picture that survives contact with a customer from one that embarrasses the person quoting it. Date every finding, because a stack detected eighteen months ago is a claim about the past. Name the source next to the claim, so a sales conversation can survive being challenged. And say how often the evidence appeared, because frequency is the only public proxy for how central something is.
The failure mode is the confident inventory: a tidy list of thirty technologies with no dates, no sources and no weighting, which reads as authoritative and cannot be defended line by line. A shorter list with a document behind each row is worth more.