Forem: Henley Wing

I analyzed 100K HubSpot customers - here's what I learned

Henley Wing — Sat, 04 Apr 2026 21:18:29 +0000

If you work at a HubSpot agency, build apps on the HubSpot platform, or just want to understand who actually uses HubSpot and how, this article is for you.

I started with the customer list published by Bloomberry, which tracks 108,269 companies running HubSpot. They find these companies by scanning DNS records, the technical config files every company publishes when they set up an email or web tool.

HubSpot leaves specific fingerprints in those records: SPF entries that authorize HubSpot to send email on a company's behalf, CNAME records pointing to HubSpot-hosted subdomains, and tracking pixels tied to HubSpot's servers. If a company is running HubSpot, those records don't lie. I took that raw list and dug in.

Here's what the data shows.

1. Software companies use HubSpot at nearly 10x the average rate.

Ranking by raw customer count is boring. Software Development comes first, then IT Services, then Financial Services. That just tells you which industries have a lot of companies in general.

The more useful metric is a multiplier: compared to all 2 million domains in the dataset, how much more likely is a company in a given industry to be running HubSpot?

Software Development comes in at 9.6x. A software company is nearly ten times more likely to be on HubSpot than the average business. Almost every software company that does marketing eventually ends up here.

2. The other over-indexing industries are more surprising than you'd expect.

After software, the industries most disproportionately likely to use HubSpot are:

Market Research (5.8x). Their entire business is built on educating buyers and building credibility over time. HubSpot's content and nurture tools are a natural fit.

E-Learning (4.9x). These companies attract, educate, and convert prospects over long consideration cycles. That's textbook inbound marketing.

Financial Services (4.4x). Fintech skews this up, but traditional financial services firms are in the mix too. Compliance constraints limit many channels, pushing companies toward owned tools like HubSpot.

Medical Equipment (3.9x) and Biotech (3.7x). Both sell through long, relationship-driven cycles to hospitals and procurement committees. A deal that takes 18 months and involves six stakeholders is exactly what HubSpot is built for.

Marketing and Advertising Services (3.5x each). Agencies use the tools they recommend to clients. HubSpot's partner program also gives certified agencies referral revenue, making adoption a business decision as much as a product one.

3. The typical HubSpot customer is smaller than most people assume.

The single biggest segment, at 42% of all users, is companies with 11 to 50 employees. Companies with fewer than 200 employees account for 86% of the entire customer base. Past 200 employees, adoption drops off as companies move toward Marketo or Salesforce Marketing Cloud.

The breakdown looks very different depending on which HubSpot product you're looking at:

Free CRM. 78% of users have fewer than 10 employees. This is not a customer base. It's a top-of-funnel acquisition strategy: get millions of tiny businesses in the door, convert the ones that grow.

Service Hub (helpdesk, live chat, knowledge base). Over half of users have fewer than 10 employees. At that scale it usually means one chat widget and a basic help center. Only 4 companies with more than 10,000 employees use it at all.

Content Hub (websites, landing pages, blogs). The most even spread of any product. Website needs exist at every company size, so the distribution is flatter across the board.

Sales Hub (CRM, pipelines, deals). Reaches furthest up the size curve. The tail at larger companies is healthier than any other HubSpot product, and 0.8% of Sales Hub users have more than 10,000 employees, compared to just 0.1% for Service Hub.

If you're selling to HubSpot customers, the specific product they run is one of the best signals you have about their size.

4. HubSpot has genuinely caught Salesforce in the mid-market.

I polled 972 sales leaders in March 2026 with one question: what is your company's main CRM?

Salesforce came in at 43% (419 companies). HubSpot at 41% (397 companies). Twenty-two companies separated them. At that sample size, that is a statistical tie.

A decade ago this wasn't close. Salesforce was the default for any company that took sales seriously, and HubSpot was a marketing tool with a free CRM bolted on. That is no longer the case.

Real companies in the poll running HubSpot as their primary CRM include Zapier, Bitwarden, GitKraken, CoinGecko, DataSnipper, UpGuard, Unstructured, and Rinsed. These are not small companies kicking the tires. They are funded, growing businesses with real sales teams operating entirely out of HubSpot.

5. HubSpot and Salesforce are not fighting over the same customers anymore.

The near-tie masks something more interesting: the two platforms have quietly split into different markets.

HubSpot wins at companies with faster sales cycles, technical buyers, and self-serve growth motions. Businesses where a prospect can sign up, try the product, and convert without ever talking to a sales rep. Bitwarden, Unstructured, Flowcode, and Rinsed all fit this profile.

Salesforce wins where deals are complex, contracts are large, and buying involves multiple departments over months. Rippling, Toast, Notion, Superhuman, and Betterment are all in that camp. These are businesses where the CRM needs deep customization and a dedicated admin team.

They're both called CRMs. They're serving increasingly different businesses. That matters a lot if you're an agency deciding which platform to specialize in.

6. Finland uses HubSpot more than any other country.

The US has the most HubSpot users in absolute terms at 48,289 companies. But adjusted for how many total businesses exist in each country, the rankings look very different.

Finnish companies are 5.9x more likely to be running HubSpot than average. Norway is at 5.1x. New Zealand at 4.6x. The US at 4.2x. Australia at 4.1x. Sweden, Denmark, and Belgium all make the top 15.

The Nordics showing up this heavily is striking. Small markets by population, but they produce a disproportionate number of tech-forward businesses that adopt modern marketing tools early.

Japan at 5.1x is the most surprising entry. American B2B SaaS tools typically struggle there due to language barriers and a preference for domestic software. Japan tying Norway suggests HubSpot has made inroads that most US software companies never manage.

Israel at 3.9x makes complete sense. One of the densest startup ecosystems in the world relative to population. Israeli startups adopt modern go-to-market tools early and HubSpot benefits from that disproportionately.

7. HubSpot is third in email marketing by domain count, and that's actually a compliment.

I looked at which email marketing tool each of the 2 million domains in the dataset was configured to use, by reading DNS records. The breakdown:

Mailchimp: 41.8%
Brevo: 16%
HubSpot: 15.1%
Klaviyo: 13.1%
Constant Contact: 4.3%
Pardot: 3.9%

Third place sounds like a demotion. It isn't. Mailchimp and Brevo users are often just sending a monthly newsletter. HubSpot customers are typically running their entire marketing operation through the platform: forms, landing pages, ad tracking, CRM, chat, support, and email all wired together. Third by domain count likely means first by revenue per customer.

8. Brevo is the story most people in the HubSpot world are ignoring.

16% market share. More customers than HubSpot by raw count. And it barely registers in most marketing technology conversations.

Brevo rebranded from Sendinblue in 2023 and has been quietly winning on price. It costs considerably less than HubSpot at almost every tier. A lot of companies land on Brevo when they outgrow Mailchimp but can't justify HubSpot's pricing, particularly in European and Latin American markets.

For HubSpot agencies and developers, this matters. Brevo represents a large pool of companies that opted out of HubSpot specifically because of cost. They're not on Salesforce. They're one clear value conversation away from switching.

The bottom line

108,269 companies are running HubSpot. It's statistically tied with Salesforce in the mid-market. Software companies adopt it at nearly 10x the average rate. The typical customer is an 11 to 50 person company, probably in tech, probably in the US or Northern Europe.

If you're a HubSpot agency, the clearest opportunity is in industries that over-index but aren't obvious: medical equipment, biotech, financial services. Complex buying cycles, real budget, and not yet heavily targeted by HubSpot-specialized agencies.

If you're a developer building on the platform, Sales Hub and Content Hub users skew larger and are worth approaching differently than Service Hub users.

And if you're just trying to understand the landscape: HubSpot is no longer a marketing tool with a CRM attached. It's a full business platform, and the data backs that up.

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

Henley Wing — Sat, 21 Feb 2026 16:33:24 +0000

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.

Part 1: Infrastructure Recon (Get your hands dirty)

1. Inspect API response headers with curl
2. Extract third-party domains from network calls
3. Read Content Security Policy headers
4. Enumerate subdomains and trace them to cloud providers
5. Search Cisco Umbrella DNS traffic logs

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

6. Look up DNS TXT records
7. Check their GitHub, NPM, and Hugging Face orgs
8. Read subprocessor lists and trust centers
9. Check their status page
10. Mine historical job postings

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/

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()

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:

Open Chrome DevTools → Network tab
Enable Preserve log
Reload and click around the app
Filter by Fetch/XHR
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

Or use subfinder:

subfinder -d company.com -silent

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

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

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

dig +short -x <IP>

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

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}")

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

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

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

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

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

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"

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."

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()

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.