Technographics Benchmark

Why precision is sampled, not whole-cohort

A whole-cohort ground truth ("company X really does use tool Y in engineering") would need either insider attestation (rare, biased, expensive) or an exhaustive audit on every cell (impractical even at modest cohort sizes). Instead, every cell's precision comes from a sampledhand audit: pull a random subset of the vendor's flags, verify each, and report the fraction that checked out.

Two ways to read the matrix:

• Sort by surfaced if you care about reach - which vendor flags the most companies for the tools you care about, regardless of how clean each flag is.
• Sort by correct if you care about trustworthiness - how many of those flags actually held up under audit. A smaller correct count from a tight vendor is often more useful than a bigger surfaced count from a noisy one.

Why "Modal", "Linear", "Plain", "Default" are the real test

Roughly half the canonical tools have names that are also common English words - "Modal" (a UI primitive), "Linear" (math), "Plain" (an adjective), "Default" (a config term), "Mercury" (a planet), "Resend" (a verb), "Gong" (an instrument), "Clay" (a material), and so on. These rows are marked with a small ^* marker in the matrix.

A vendor whose detection is built on naive keyword match against job posts or web copy will inflate the "surfaced" count on these rows with false positives - every JD that mentions "modal dialog", "linear progression", or "default values" gets miscounted as a buying signal. A vendor doing entity disambiguation (context, vendor URL match, co-occurrence with role titles, capitalization rules) will hold its precision steady.

This is the whole reason the precision column exists. Two vendors can both report "300 companies using Modal" and look identical at the surface - until you audit. The vendor at 92% precision actually found 276 real Modal customers; the vendor at 38% only found 114. Always read these rows with the sort flipped to correct.

How each vendor was queried

Every vendor exposes a different surface - public API, web fingerprint, jobs feed, third-party signals - so the ingestion logic is per-vendor. Each script in scripts/ingest_*_technography.py writes the resulting counts into data/latest-technography.json.

• OpenFunnel· queries an internal LinkedIn jobs index (linkedin-jobs-search, ~365d lookback). For each tool we run a match_phrase over title OR description and aggregate distinct company_slug via an OpenSearch cardinality (HyperLogLog, precision_threshold=40k). Filters out garbage slugs ("", https:, http:) and excludes the vendor's own careers postings. For tools whose name is a common English word, the search term is narrowed to a disambiguated form (e.g. Outreach → "Outreach.io") - high precision, lower recall. All 40 cells live. Structural ceiling: LinkedIn only, vs. TheirStack's multi-board index.
• TheirStack · POST /v1/companies/search with job_filters.job_technology_slug_or = [tool_slug] and posted_at_max_age_days = 365. Reads metadata.total_results. Slug-overrides map tools whose canonical name doesn't match TheirStack's tech taxonomy (MotherDuck → motherduck, Customer.io → customer-io, …). Rate-limited at 50/hour, with backoff parsed from ratelimit-reset headers.
• Sumble · POST /v6/technologies/find with { query: tool_name }. Returns up to 50 related "technologies" via substring match. Per-tool aggregation rule: ambiguous tools (Modal, Linear, Outreach, …) sum only the variant whose slug equals the canonical slug; unambiguous tools sum the product family - canonical slug plus any slug prefixed with canonical-, so NetSuite captures netsuite + netsuite-implementation + netsuite-administrator… while dropping quorum/forumnoise on a query for "Orum". Includes a vendor-rename override (Marketo → adobe-marketo, post-acquisition).
• PredictLeads · GET /v3/discover/technologies/{fuzzy}/technology_detections?page=1&limit=1. Passing page=1 is required: per the docs, PredictLeads omits meta.count from the response unless a page is requested. The limit=1 keeps the per-tool cost at 1 credit. Result lands as the company count. Fuzzy-name lookup handles most tools directly; 1 cell errored (no fuzzy match for Lindy).
• BuiltWith · GET /trends/v6/api.json?TECH={name} on the free Trends endpoint (0 credits per call). Reads Tech.coverage.live - current sites running the tool. The paid Lists API would give a richer per-site breakdown but requires a subscription. Casing-sensitive overrides: HubSpot → Hubspot, Reclaim → Reclaim-AI. BuiltWith is structurally blind to ~40% of our catalog (dbt, Modal, Ramp, Plain, Pylon, Clay, Pave, Granola, … - tools that don't leave a public-web fingerprint). Those cells render as -, not 0.

A 0from any vendor is treated as "not in this vendor's catalog" (or no detection in the lookback window) and persisted with audited_at: null, so the cell renders as -. Real coverage gaps are visible at a glance.

What this benchmark does not tell you

• Surface bias.BuiltWith only sees what renders on the public web; it's blind to ~40% of our catalog (dbt, Modal, Ramp, Plain, Pylon, Clay, Pave, Granola, Lindy, … - internal SaaS without a website fingerprint). Those cells are -, not zero.
• Job-posting bias. Job-derived vendors (OpenFunnel, TheirStack, Sumble) only surface tools that appear in postings. Stable stacks with little hiring activity are underrepresented; growth orgs are over-indexed.
• Source-set bias inside the same surface. OpenFunnel indexes LinkedIn only; TheirStack and Sumble aggregate LinkedIn + Indeed + Greenhouse + Lever + Ashby + others. That alone accounts for a ~2-3× recall gap on unambiguous tools (NetSuite: OpenFunnel ~17k vs Sumble 70k vs TheirStack 52k).
• Lookback windows differ.OpenFunnel and TheirStack use a strict 365-day window. Sumble and PredictLeads return all-time observations from their catalogs. BuiltWith's coverage.liveis "currently detected" (rolling). Direct count comparisons across vendors should be read as order-of-magnitude, not exact.
• Resolution rules vary. Sumble matches by substring across product variants; we wrap that in a family-prefix filter (canonical + canonical-*) to drop substring noise (quorum, forum, …). TheirStack runs entity disambiguation server-side and returns small, tight counts. OpenFunnel runs naive match_phrase by design - its recall ceiling is high, its precision ceiling is the whole point of the benchmark.
• Precision sample size varies. Audits are queued - current matrix shows surfaced counts only. Once audits land, a cell audited at n=10 has a much wider confidence interval than one at n=30. Cell tooltip will show sample size.
• Taxonomy mapping is opinionated.Each vendor uses a different category schema; we re-bucket to our 8 canonical departments. Edge cases ("growth tooling" → marketing or sales?) are decided once and applied consistently across all vendors.

Inclusion queue and how to request a provider

Live: OpenFunnel, BuiltWith, TheirStack, Sumble, PredictLeads.

Requested but no technographic product: ZoomInfo, Apollo, Clay. None expose a programmatic technographic endpoint we can query.

Under review next: HG Insights, 6sense/Slintel, Wappalyzer, Datanyze, Coresignal (job-derived), Ocean.io.

To request a provider, email founders@openbenchmarks.com with a link to the public API docs and pricing page.