DEV Community

Henley Wing
Henley Wing

Posted on

How to Find Any Company's Tech Stack (A Developer's Guide)

#webdev

Let me be upfront about why most tech stack tools are kind of useless for developers.

Tools like Wappalyzer and BuiltWith scrape cookies, meta tags, and frontend JavaScript. They'll tell you a company uses React and Google Analytics. Cool. But you probably already guessed that.

What you actually want to know is: what does their backend look like? What's their data infrastructure? Do they use Datadog or Grafana for observability? What does their auth layer look like?

That information doesn't show up in a browser. It lives in DNS records, HTTP headers, subdomains, job postings, and public repos. And you can get all of it for free if you know where to look.

This guide is organized by depth — starting with the most technical, developer-specific methods and working toward the simpler passive ones. Skip to whatever level you need.

Table of Contents

Part 1: Infrastructure Recon (Get your hands dirty)

Part 2: Passive Signals (High signal, zero effort)

Part 1: Infrastructure Recon

1. Inspect API response headers with curl

This is the fastest technique in this entire guide for developers. Most companies expose an API at a predictable URL — api.company.com or api.company.io. You don't need credentials. Just hit it and read what comes back.

curl -sI https://api.company.com/
Enter fullscreen mode Exit fullscreen mode

Even a 401, 403, or 404 response is packed with information. The infrastructure fingerprints itself in the headers.

Here's what you're looking for:

Header What it means
Apigw-Requestid AWS API Gateway
X-Amzn-RequestId AWS Lambda / API Gateway
X-Cache: Hit from cloudfront AWS CloudFront CDN
X-Kong-* Kong API Gateway
X-Azure-Ref Azure API Management
Server: AkamaiGHost Akamai CDN
Server: cloudflare Cloudflare
Server: openresty Nginx-based (common with Kong)
X-Powered-By: Express Node.js + Express
X-MuleSoft-* MuleSoft API management
X-Apigee-* Google Apigee
Server: Mashery Proxy Mashery/TIBCO API management
x-envoy-upstream-service-time Envoy proxy (often means Istio service mesh)
Via: 1.1 vegur Heroku routing layer
x-vercel-* Vercel deployment
x-render-* Render deployment

Example: Running curl -sI https://api.utilimarc.com/ returns a 404, but the Apigw-Requestid header is a dead giveaway for AWS API Gateway. The Apigw- prefix is specific to AWS — no other provider uses it.

Go further: Also try curl -sI https://company.com to check their web infra. The CDN, load balancer, and sometimes even the backend framework leak through the top-level domain's headers too.

2. Extract third-party domains from network calls

Every page load is a treasure map. The browser fetches scripts, fonts, pixels, and analytics from dozens of third-party services — all of which have unique hostnames that identify the vendor.

Open Chrome DevTools (F12), go to the Console tab, and run:

[...new Set(
  performance.getEntriesByType("resource")
    .map(r => {
      try { return new URL(r.name).hostname }
      catch { return null }
    })
    .filter(Boolean)
)]
  .filter(h => !h.includes(location.hostname))
  .sort()
Enter fullscreen mode Exit fullscreen mode

This gives you every distinct third-party hostname loaded by the page, deduplicated and sorted, with the first-party domain filtered out.

What you'll typically find:

  • Observability: browser-intake.datadoghq.com, ingest.sentry.io, rs.fullstory.com
  • Feature flags: app.launchdarkly.com, events.split.io, featureflags.statsig.com
  • A/B testing: api.eppo.cloud, cdn.optimizely.com
  • CDN/infra: cdn.company.cloudfront.net (CloudFront), *.fastly.net
  • Auth: company.auth0.com, cognito-idp.*.amazonaws.com
  • Logging/metrics: logs.browser-intake-datadoghq.com, api.honeycomb.io

Pro tip: Do this on the authenticated app (app.company.com), not just the marketing site. The marketing page is often a static site or different stack entirely. The actual product is where the interesting infra shows up — real-time event pipelines, feature flagging, product analytics, the works.

Paste the hostname list into an LLM and ask it to map each domain to a product. This is faster and more up-to-date than any static tool, since new vendor domains get recognized immediately.

3. Read Content Security Policy headers

CSP is a security feature that tells browsers which domains a site is allowed to load resources from or send data to. But for your purposes, it's a complete manifest of vendor integrations — because if a domain is in the CSP, the app is explicitly using it.

How to find it:

  1. Open Chrome DevTools → Network tab
  2. Enable Preserve log
  3. Reload and click around the app
  4. Filter by Fetch/XHR
  5. Click any request → Headers → look for Content-Security-Policy

The CSP will be a long string of directives like connect-src, script-src, and img-src, each followed by a list of allowed domains.

Real example from Monday.com's CSP:

  • monday.zendesk.com → uses Zendesk for support
  • monday.lightning.force.com → Salesforce integration
  • monday.vitally.io → Vitally for CS
  • o474786.ingest.sentry.io → Sentry for error tracking
  • *.launchdarkly.com → LaunchDarkly for feature flags
  • app.datadoghq.com → Datadog for observability

Copy the entire CSP value and throw it into an LLM: "What developer tools and SaaS products correspond to these domains in this Content Security Policy?" You'll get a categorized breakdown in seconds.

Note: Not every site sets a CSP, and CSPs are sometimes set only on certain responses. If you don't see it, move on — but when it's there, it's one of the most explicit tech signals available.

4. Enumerate subdomains and trace them to cloud providers

Companies don't run everything on www. As infrastructure grows, services get their own subdomains — owned by different teams, deployed independently, with separate access controls. And they're often named very literally.

A subdomain called kafka-prod-b2.company.com tells you exactly what's running there. Same for elastic.company.com, grafana.internal.company.com, or consul.company.com.

Finding subdomains:

The easiest free option is pentest-tools.com — they give you two free reports, which is enough for a research session. Enter the domain and get a list of discovered subdomains.

For a command-line approach, Amass is the gold standard:

amass enum -passive -d company.com
Enter fullscreen mode Exit fullscreen mode

Or use subfinder:

subfinder -d company.com -silent
Enter fullscreen mode Exit fullscreen mode

Real example — Nokia's subdomains:

elastic0.cbrs.iot.nokia.com         → Elasticsearch
kafka-prod-b2.enso.saas.nokia.com   → Kafka in production
pfsense.iot.nokia.com               → pfSense firewall
grafana.cbrs.iot.nokia.com          → Grafana dashboards
consul.cbrs.iot.nokia.com           → HashiCorp Consul
Enter fullscreen mode Exit fullscreen mode

Just reading the names: they're running an ELK-adjacent stack with Kafka for streaming, Consul for service discovery, and Grafana for dashboards. That's a detailed architecture picture without touching a single line of code.

Trace subdomains to cloud providers:

Once you have a list, run dig on interesting ones:

dig +short kafka-prod-b2.enso.saas.nokia.com
Enter fullscreen mode Exit fullscreen mode

Then look up the IP in a tool like ipinfo.io or just check the PTR record:

dig +short -x <IP>
Enter fullscreen mode Exit fullscreen mode

If it resolves to *.compute.amazonaws.com → AWS. *.googleusercontent.com → GCP. *.azure.com → Azure. Repeat across a few subdomains and you'll quickly see which cloud(s) they're on. Many large companies are multi-cloud, and the subdomain patterns often tell you which workloads live where.

5. Search Cisco Umbrella DNS traffic logs

This one is genuinely underused and feels like a cheat code.

Cisco Umbrella (formerly OpenDNS) operates one of the world's largest DNS resolver networks. Every day, they publish the top 1 million most queried domains and subdomains through their infrastructure — the Cisco Umbrella Popularity List. It's free, public, and updated daily.

Why this is different from subdomain enumeration: enumeration tools find subdomains that exist. The Umbrella list shows subdomains that are actively being used, based on real DNS traffic. This means you'll catch third-party SaaS tools with company-specific subdomains that would never appear in a passive scan.

Download and search it:

# Download
curl -O http://s3-us-west-1.amazonaws.com/umbrella-static/top-1m.csv.zip
unzip top-1m.csv.zip

# Search for a company
grep -i "autodesk" top-1m.csv
Enter fullscreen mode Exit fullscreen mode

Or do it in Python:

import csv

company = "autodesk"
with open("top-1m.csv") as f:
    reader = csv.reader(f)
    matches = [(rank, domain) for rank, domain in reader if company in domain.lower()]

for rank, domain in matches:
    print(f"Rank {rank}: {domain}")
Enter fullscreen mode Exit fullscreen mode

What I found when searching for "autodesk":

autodeskfeedback.az1.qualtrics.com     → Qualtrics for surveys
autodesk.enterprise.slack.com          → Slack Enterprise Grid
autodesk.pagerduty.com                 → PagerDuty for incident management
autodeskglobal.okta.com                → Okta for identity/SSO
autodeskglobal-ssl.mktoweb.com         → Marketo for marketing automation
autodesk.splunkcloud.com               → Splunk for log analysis
*.autodesk.com.edgekey.net             → Akamai CDN
notifications.api.autodesk.com         → Dedicated notifications microservice
Enter fullscreen mode Exit fullscreen mode

From one grep, you can see their incident management stack (PagerDuty), their identity provider (Okta), their SIEM (Splunk), and their CDN (Akamai). Paid technographic tools almost never surface these, because they focus on frontend detection.

Caveat: This only works for companies with enough external traffic to appear in the top million. Smaller startups likely won't show up. But for anything mid-size or larger, it's one of the highest-signal free techniques available.

Part 2: Passive Signals

These methods require less technical effort but often reveal tools that the recon techniques above will completely miss — especially backend business tooling, internal SaaS, and vendor relationships.

6. Look up DNS TXT records

When a SaaS tool needs to verify domain ownership for SSO or SAML integration, they require you to add a TXT record to DNS. These records persist long after the integration is live. They're public, unfakeable, and one of the strongest signals that a company actually uses a product.

Command line:

dig TXT company.com +short
# Or for more detail:
dig TXT company.com ANY
Enter fullscreen mode Exit fullscreen mode

Or use a GUI: dnschecker.org → choose "TXT" record type.

Real example — OpenAI's TXT records reveal:

notion-domain-verification=...        → Notion
atlassian-domain-verification=...     → Jira / Confluence
docker-verification=...               → Docker Hub
postman-domain-verification=...       → Postman
ms-domain-verification=...            → Azure AD / M365
miro-verification=...                 → Miro
Enter fullscreen mode Exit fullscreen mode

Other dev-tool-related patterns to look for:

TXT record prefix Product
docker-verification Docker Hub
postman-domain-verification Postman
atlassian-domain-verification Jira, Confluence
stripe-verification Stripe
datadog-... Datadog
pagerduty-verification PagerDuty
github-challenge-... GitHub Enterprise / SSO
1password-site-verification 1Password Teams
sentry-... Sentry
linear-... Linear

If a verification record exists, someone on the IT or infra team had to explicitly add it. That's a confirmed active integration.

7. Check their GitHub, NPM, and Hugging Face orgs

Takes about 60 seconds and often reveals the most direct, unambiguous evidence of what a company actually builds with.

GitHub

Start at github.com/{company-name}. Even if it's not linked from their website, it's usually guessable. Try the obvious names.

What to look at:

Language breakdown: GitHub shows a bar graph of languages across public repos. 40 repos in Go? That's a Go shop. Python-heavy with some Rust? That's a signal too.

Repo names: Companies often open-source internal tooling, SDKs, and infrastructure modules. Names like company-terraform-modules, company-kafka-consumer, or company-k8s-operators are literal descriptions of their infra.

Dependency files: Open any repo and check:

# Node projects
cat package.json | jq '.dependencies, .devDependencies'

# Python projects  
cat requirements.txt
cat pyproject.toml

# Go projects
cat go.mod

# Ruby
cat Gemfile

# Java/Kotlin
cat build.gradle
cat pom.xml
Enter fullscreen mode Exit fullscreen mode

You don't need to understand the code. Just read the dependency names. A Python repo importing pyspark, delta-spark, and airflow tells you their data engineering stack. A Node repo pulling in @opentelemetry/api tells you they're doing structured observability with OpenTelemetry.

GitHub Actions workflows: This is often overlooked. Check .github/workflows/ in any repo. The workflow YAML files show their CI/CD setup, which testing tools they use, and what cloud they deploy to:

# Look for things like:
# - uses: aws-actions/configure-aws-credentials  → AWS
# - uses: google-github-actions/auth             → GCP
# - uses: hashicorp/setup-terraform              → Terraform
# - uses: docker/build-push-action               → Docker
Enter fullscreen mode Exit fullscreen mode

NPM

Search npmjs.com for the company name, or try npmjs.com/~{org-name}. Published packages reveal the frontend frameworks they use and what internal tools they've built and open-sourced. A company publishing a design system built on React and Storybook tells you a lot about their frontend stack.

Hugging Face

Head to huggingface.co/{company-name}. Useful for any company doing ML work:

  • Models: What architectures are they using? Fine-tuning on what base models?
  • Datasets: What kind of data do they work with?
  • Spaces: Demo apps that show their framework choices (Gradio, Streamlit, etc.)
  • Team size: The member count gives a rough sense of ML team scale.

8. Read subprocessor lists and trust centers

Companies that handle personal data — especially for EU customers — are often legally required to disclose every third-party service that touches that data. These are subprocessors, and the lists get published in "Trust Center" or "Security" pages.

For developers, this is the fastest way to find out what SaaS infra a company is paying for: cloud providers, auth platforms, monitoring tools, data platforms.

How to find them:

Google: "[company name] subprocessors"
Google: "[company name] trust center"
Look: footer links labeled "Trust," "Security," or "Privacy"
Enter fullscreen mode Exit fullscreen mode

Example from NewDays.ai's Trust Center:

Just from one screenshot, you can confirm: AWS for cloud, Auth0 for authentication, Sentry for error monitoring. That's three confirmed infrastructure choices in 30 seconds.

If the list is long, paste it into an LLM and ask it to group by function: "Here is a subprocessor list. Categorize each vendor by function: cloud infrastructure, auth/identity, observability, data storage, CI/CD, etc."

Not every company publishes one. But when they do, it's the most honest signal available — it's literally a receipt of their operational stack.

9. Check their status page

Status pages (status.company.com, or hosted on Atlassian Statuspage, Instatus, or Better Uptime) are designed for customer communication. But they contain two things that are valuable for tech recon:

The components list reveals architecture. The way a company breaks down their services tells you a lot. Separate components for US-East, EU-West, and APAC confirm multi-region. Separate statuses for API, WebSockets, Background Jobs, and CDN tell you how they've segmented their infrastructure.

Incident history reveals hidden dependencies. When systems fail, companies explain why — and that explanation often names an upstream vendor. This is especially powerful for finding security and infrastructure tools that never show up in DNS or network calls.

Example: After the CrowdStrike outage on July 19, 2024, dozens of companies posted status page incidents explicitly mentioning CrowdStrike. No scanner, DNS lookup, or job posting would ever reveal a company uses CrowdStrike EDR. But their own status page did.

The technique: if a vendor had a major outage on a known date, search status pages for companies that reported issues on the same day mentioning that vendor. You now have a list of confirmed customers.

10. Mine historical job postings

When a company hires, they list the exact tools the hire will use. Engineering roles are obvious, but also look at: SRE and DevOps postings (infra stack), data engineering roles (pipeline tools), platform engineering (internal dev platform), and security roles (SIEM, EDR, vulnerability management).

The problem: Most companies only have a few active listings, and old ones disappear from LinkedIn and career pages.

The solution: The Wayback Machine.

Paste the company's careers page URL (not an individual job listing) into the Wayback Machine and you'll find archived snapshots going back years. Browse old job listings that are no longer live and collect the technologies mentioned.

Once you've collected 8–10 postings across different roles:

Paste all job descriptions into an LLM and ask:
"Extract every specific technology, tool, framework, or platform 
mentioned across these job descriptions, count how many postings 
each appears in, and group them by category."
Enter fullscreen mode Exit fullscreen mode

Frequency is the signal. If Terraform, Kubernetes, and ArgoCD show up across 6 out of 8 engineering postings, that's the real infra stack. If Jenkins shows up once in a posting from 2021, they've probably moved on.

Don't only look at engineering jobs. A Platform Engineering posting mentioning Backstage tells you they're building an internal developer platform. An SRE posting mentioning PagerDuty, Prometheus, and Grafana tells you their observability stack. A Data Engineering posting mentioning dbt, Airflow, and Snowflake tells you their data warehouse setup.

Putting It All Together

Different techniques reveal different layers of the stack. Here's a practical workflow depending on what you're trying to find:

"What cloud/infra do they run?"
→ Subdomain enumeration → dig A records to cloud IP ranges → curl API headers

"What does their observability stack look like?"
→ Extract third-party domains from network requests → Job postings (SRE/DevOps roles) → DNS TXT records for tools like Datadog, New Relic, Honeycomb

"What's their data/ML infrastructure?"
→ GitHub repos (look for Airflow DAGs, dbt models, Spark configs) → Hugging Face org → Job postings for data engineers

"What does their auth/security stack look like?"
→ DNS TXT records (okta-domain-verification, onelogin-domain-verification) → Subprocessor lists → Status page incidents mentioning security vendors

"What CI/CD and dev tools do they use?"
→ GitHub Actions workflows in public repos → DNS TXT records (GitHub, Postman, Docker) → Job postings for platform/DevOps roles

Quick Reference 

# API header fingerprint
curl -sI https://api.company.com/

# DNS TXT records
dig TXT company.com +short

# Subdomain enumeration
subfinder -d company.com -silent | tee subdomains.txt

# Trace subdomain to cloud
dig +short company.com | xargs -I{} curl -s ipinfo.io/{}

# Cisco Umbrella search
curl -O http://s3-us-west-1.amazonaws.com/umbrella-static/top-1m.csv.zip
unzip top-1m.csv.zip && grep -i "company" top-1m.csv

# Browser: extract third-party domains
[...new Set(performance.getEntriesByType("resource").map(r=>{try{return new URL(r.name).hostname}catch{return null}}).filter(Boolean))].filter(h=>!h.includes(location.hostname)).sort()
Enter fullscreen mode Exit fullscreen mode

Every technique here is free. The recon tools (Amass, subfinder) are open-source. The DNS lookups are public by design. The Cisco Umbrella list is published daily. GitHub repos and NPM packages are intentionally public.

I also built an API around these techniques. I released it here in Github if you want to poke around.

If you're lazy, and looking for free/paid tools that do all or any of the above, I compiled a huge list of tech stack lookup tools you can use as an alternative to Wappalyzer or Builtwith.

Top comments (0)