How to find any company’s tech stack (without paying a single cent)

Last Updated: February 1, 2026

How do you find out what technologies a company actually use? And I’m not talking about just the frontend frameworks, but the real stuff: observability tools, data infrastructure, cloud providers, internal services, etc.

The lazy way is to pay for a tool like BuiltWith or Wappalyzer or one of the many paid alternatives to Wappalyzer. But here’s the thing: those tools mostly scrape cookies and frontend libraries. They miss everything that doesn’t show up in a website. Which is most of it.

The better way is to do what any curious hacker would do: look where the paid tools don’t bother looking. None of this requires a CS degree or any serious coding. Just some free tools, a bit of sleuthing, and an LLM to pattern-match the results.

1) Use a tool to enumerate internal subdomains of a domain

One place companies accidentally expose a ton of information is their subdomains.

That’s because most companies don’t run everything on www.company.com. As systems grow, they split things up. Different services get their own subdomains so they can be owned by different teams, deployed independently, and locked down with different security rules.

That’s why you’ll see names like:

• auth.company.com
• api.company.com
• billing.company.com
• kafka-prod.company.com
• elastic.company.com

These names aren’t random. They usually describe exactly what the service does. And because of that, a list of subdomains often tells you more about a company’s real infrastructure than any paid scanner ever will.

How do I find internal subdomains of a domain?

A very easy way to do this is with pentest-tools.com. They give you two free reports, which is more than enough for research.

Drop in a domain and you’ll get a list of discovered subdomains.

For example, if you try this with nokia.com, this is what you get back:

You’ll see things like:

• elastic0.cbrs.iot.nokia.com
• kafka-prod-b2.enso.saas.nokia.com
• pfsense.iot.nokia.com
• datasync0.cbrs.iot.nokia.com

You don’t need to be technical to get value from this. Just reading the names already tells you a lot:

• they use Elasticsearch
• they use Kafka
• they use pfSense
• they have IoT-specific infrastructure
• they separate environments and products via naming

Not very technical? Don’t overthink it. Paste the subdomains into ChatGPT.

If you’re not sure what a subdomain means, don’t try to decode it yourself.

Just copy the full list of subdomains and paste them into ChatGPT with a prompt like: “You’re looking at a list of subdomains used by a company. Based on the names, infer what infrastructure services or technologies they likely represent. Call out anything obvious (databases, messaging systems, auth, observability, internal tools), and point out anything interesting.”

ChatGPT will quickly show you patterns you might have missed. Things like Kafka clusters, Elasticsearch, auth systems, regional deployments, or internal services usually jump out immediately.

This is a recurring theme in this guide: collect raw signals, then let AI do the pattern matching.

A few things to keep in mind:

• this doesn’t work for every company
• some companies lock this down tightly
• some subdomains are boring or generic

That’s fine. When it works, it works very well. When it doesn’t, move on to the next technique.

Once you have a list of internal subdomains, you can go one step further and figure out which cloud platform they actually run on.

Take a handful of those subdomains and plug them into a free tool like:
https://dnschecker.org/

Look at the A record. DNS Checker will usually tell you who owns the IP address.

For example, when you look up: kafka-prod-b2.enso.saas.nokia.com

DNS Checker shows that the IP is owned by Amazon Technologies Inc. That’s a very strong signal this service is running on AWS.

Repeat this for a few different subdomains and patterns emerge quickly. If most of them resolve to Amazon, Google, or Microsoft IP ranges, you can safely assume that’s where the bulk of their infrastructure lives.

Why can’t you just just check the main domain?

You might be wondering why not just look up the main homepage nokia.com and call it a day.

Two reasons:

1. Frontends are usually hidden behind CDNs
   Most company websites sit behind Cloudflare, Fastly, or another CDN. That tells you almost nothing about where their real services run.
2. Backends often live elsewhere
   It’s very common for a company’s marketing site to be on one platform while their internal services run on another. The real infrastructure is almost always behind internal or product-specific subdomains.

That’s why checking individual service subdomains works, and checking the main domain usually doesn’t.

You don’t need to inspect every subdomain. A small sample is enough to get a clear answer on what major cloud platforms a company uses.

2) Search Cisco Umbrella’s DNS popularity logs

Here’s a technique that feels a bit like finding a secret door in a video game.

Cisco operates one of the largest DNS resolver networks in the world through their Umbrella service (formerly OpenDNS). Every time someone on their network visits a website, that DNS query gets logged. And every day, Cisco publishes a ranked list of the most popular domains and subdomains that flow through their infrastructure. It’s called the Cisco Umbrella Popularity List, and it’s completely free to download.

Why this is different from subdomain enumeration:

Earlier, I mentioned using tools like pentest-tools.com to find subdomains. Those tools work by querying DNS records and certificate transparency logs. They find subdomains that exist.

The Cisco Umbrella list is different. It shows subdomains that are actively being used based on real traffic. This means you’ll catch things that technically exist but wouldn’t show up in a standard DNS scan, like third-party SaaS platforms with company-specific subdomains, or internal tools that only employees access.

Cisco publishes the list daily to a public S3 bucket. You can download it directly:

http://s3-us-west-1.amazonaws.com/umbrella-static/top-1m.csv.zip

Unzip it and you’ll get a simple CSV with two columns: rank and domain. The rank is based on traffic volume, so rank 1 is the most visited domain across Cisco’s entire resolver network.

Next, open the CSV in your favorite spreadsheet tool or text editor, and search for the company name you’re researching. You’ll get back every subdomain containing that name that made it into the top million.

What you’ll find:

When I searched for “autodesk” in the file, I found entries like this:

Just scanning through the results, you can spot a bunch of third-party services:

• autodeskfeedback.az1.qualtrics.com → they use Qualtrics for surveys and feedback collection
• autodesk.enterprise.slack.com → they use Slack Enterprise Grid (the enterprise version, not the free tier)
• autodesk.file.force.com → they use Salesforce
• *.autodesk.com.edgekey.net → they use Akamai as a CDN (edgekey.net is Akamai’s domain)
• autodeskglobal-ssl.mktoweb.com → they use Marketo for marketing automation
• lrs-main.learn-one.autodesk.com and learnacc.autodesk.com → some kind of internal learning/training platform
• screencast.autodesk.com → possibly hosting product demos or tutorials
• notifications.api.autodesk.com → they have a notifications API (useful to know if you’re interviewing for an infrastructure role)

You’ll also catch internal-looking subdomains that standard enumeration tools might have missed, like proc.autodesk.com or foundationapi.autodesk.com. These hint at internal systems and microservices architecture.

Now a caveat: This only works for companies with enough traffic to show up in the top million. Smaller startups probably won’t appear. But for mid-size and enterprise companies, it’s a goldmine of real-world infrastructure signals.

Most paid technographic tools scrape websites and call it a day. They have no idea what’s happening at the DNS level. The Umbrella list shows you actual traffic patterns, which means you’re seeing what the company really uses day to day, not just what’s loaded on their marketing homepage.

3) Hit their API endpoint and examine the response headers

Here’s one more trick that takes about 10 seconds.

Most companies expose an API at a predictable URL like api.company.com. Even if you don’t have credentials, just hitting that endpoint and looking at the error response can tell you what infrastructure they use to manage their APIs.

You don’t need to actually use the API. You just need to see the headers that come back.

How to do this:

1. Open Chrome
2. Go to https://api.{company}.com/ (or check their developer docs for the API base URL)
3. You’ll probably get an error page. That’s fine.
4. Right-click → Inspect → Network tab
5. Refresh the page
6. Click on the request that failed
7. Look at Response Headers

What to look for:

The Server header is the obvious one. But also look for vendor-specific headers that give away what they’re running.

Example 1: Macy’s

When I hit https://api.macys.com/, I get a 596 error. But look at the response headers:

See that Server: Mashery Proxy header? That tells you Macy’s uses Mashery (now part of TIBCO) for their API management platform.

You can also see Akamai-Grn which confirms they use Akamai as their CDN.

Example 2: Utilimarc

When I hit https://api.utilimarc.com/, I get a 404. But the response headers reveal:

That Apigw-Requestid header is a dead giveaway for AWS API Gateway. Only AWS adds that specific header format.

Here are some common headers and what they reveal: (but again, use ChatGPT or Claude if you want the complete picture)

This won’t tell you everything. But if you specifically want to know what a company uses for API infrastructure, this is the fastest way to find out.

4) Analyze the company’s DNS records to see what SaaS products they use.

If you’ve worked at any mid-size or large company, you probably don’t login with an username and password for every tool. You log in with SSO, usually SAML, sometimes OAuth. Before that works though, the SaaS vendor needs proof that your company actually owns the domain.

The most common way to do this is by asking your company to add a TXT record to their DNS. That record is not optional, and it’s not decorative. Someone on the IT or security team had to explicitly add it so the integration could go live.

This is why DNS records are such a strong signal. If a TXT record exists, the company is almost certainly using that product.

Most of these TXT records follow predictable naming conventions like vendor-domain-verification, vendor-verification, or something similar. They’re boring, explicit, and extremely honest.

To find them, just use a free tool like DNSChecker and look up all TXT records for the domain. No login required, no payment, no tricks.

As an example, here are some of the TXT records you’ll find for openai.com:

There’s a lot you can infer on what products OpenAI uses here:

• notion-domain-verification → Notion
• atlassian-domain-verification → Jira, Confluence
• miro-verification → Miro
• docker-verification → Docker
• wrike-verification → Wrike
• ms-domain-verification → Microsoft (Azure AD, M365)
• postman-domain-verification → Postman

This technique works especially well for companies with SSO-heavy environments, because every SaaS product needs its own verification. Paid tools like Wappalyzer often miss these entirely because they focus on front-end detection instead of configuration data.

5) Extract third-party domains from network calls on their website

OK, now this is the end of detecting the back-end infrastructure services.

How about the website? The third-party JavaScript and libraries loaded on their website.

It’s only the front end, but you’ll still learn a lot about their frameworks, analytics, observability tooling, and customer data stack.

First, go to the company’s website (their homepage) in Chrome, right click anywhere on the page, click Inspect and go to the “Console” tab.

Now copy and paste this Javascript code into your Console. This extracts all the 3rd party domains that are being referenced anywhere on the website (ie. a Javascript file)

[...new Set(
  performance.getEntriesByType("resource")
    .map(r => {
      try {
        return new URL(r.name).hostname
      } catch {
        return null
      }
    })
    .filter(Boolean)
)]

You’ll get a list of subdomains back. As an example, here’s what I see when I do this in perplexity.ai:

Great. Isn’t this something Wappalyzer can easily tell me? Why do I need to do this, when I can just install a browser extension?

Here’s why: Because there are constantly new frontend tools that come up everyday and Wappalyzer doesn’t update their code to detect these tools.

And this is where AI can help, because they can actually do this 3rd party domain => tool conversion, as it has more knowledge on these newer tools.

What you should do is paste that list into ChatGPT or Claude with a prompt like:“Based on these domains, list the technologies and products this company uses, grouped by category. If you’re not sure what technology it belongs to, try to search for it”

When I did this for perplexity.ai, I was able to found out Perplexity uses Cloudflare as a CDN, Next.js as their frontend framework, DataDog for observability, Eppo for A/B testing and experimentation, and Singular for marketing attribution.

Now, to take this a step further, if the company also has a web app, you should do the same exact thing when you login to the web app (ie. app.domain.com). Because different libraries sometimes get loaded in a web app that don’t get loaded in a company’s homepage (such as product analytics, and A/B testing products)

6) Look at the domains listed in a site’s Content Security Policy

We’re still sticking to things you can see directly from a website.

Some websites return a header called Content Security Policy on certain requests. When they do, it often contains a plain list of domains.

A Content Security Policy is basically a security rule the website sends to your browser that says “these are the domains I’m allowed to load things from or send data to.”

If a domain appears in this list, the app is basically explicitly allowed to interact with it.
And that usually means the company uses whatever service lives at that domain.

What this looks like in the real world

Look at the screenshot above.

This is from Monday.com. I clicked around the app, opened the Network tab, clicked on each XHR request, and found one that listed a Content-Security-Policy.

What do you see?

A long list of domains like:

• msteams.backend.monday.app
• monday.zendesk.com
• monday.lightning.force.com
• *.microsoft.com
• *.office.com
• monday.vitally.io

From just that list, you can already tell:

• they integrate deeply with Microsoft Teams
• they use Salesforce
• they use Zendesk
• they use Vitally

How to do this yourself (simple steps)

1. Open the website in Chrome
2. Right-click → Inspect
3. Go to the Network tab
4. Turn on Preserve log
5. Reload the page
6. Click around the site or app like a normal user
7. Filter by Fetch/XHR
8. Click a request to an internal endpoint
9. Scroll in Headers until you see Content-Security-Policy
10. Copy the entire list of domains

That’s it.

Two things to know:

• Not every website exposes this. Some won’t show anything at all.
• Even on sites that do, only some requests will include it.

That’s normal. If you don’t see it, move on to the next technique. This is just one signal, not a universal trick.

Don’t analyze it yourself. Paste it into ChatGPT.

Once you’ve copied the list, don’t try to decode it manually (unless you love brain damage)

Paste it into ChatGPT and ask: “Extract all domains from this list and tell me what products or services they likely belong to. Group them by function and point out anything interesting.”

You’ll get a clean summary of the tools, integrations, and infrastructure the company is using.

When a site exposes a Content Security Policy like this, it’s one of the clearest signals you’ll get. It’s a straight list of who the app is allowed to talk to.

Sometimes you won’t see it. Sometimes you do. And when you do, you often learn an awful lot about what tools a company uses.

7) Inspect their subprocessor lists and/or privacy policy

Here’s a trick that requires zero technical skill: just read what companies are legally required to tell you.

If a company handles personal data (especially in the EU or if they’re SOC 2 compliant), they usually have to disclose every third-party service that touches that data. These are called subprocessors, and companies publish them in plain English, often in a dedicated “Trust Center” or “Security Center” page.

What you’ll find here is gold: the actual vendors they pay money to. We’re talking cloud providers, analytics tools, payment processors, customer support platforms, email services. Basically a receipt of their operational stack.

Tech startups especially love publishing Trust Centers because it signals to enterprise buyers that they take security seriously. Which means they’ll openly list every SaaS product touching their infrastructure.

Here’s an example from NewDays.ai’s Trust Center:

Just from this snippet, you can already see they use:

• AWS for cloud infrastructure
• Auth0 for authentication
• Sentry for error monitoring
• Zoom for video calls (and they’re handling health data, so HIPAA-compliant Zoom at that)

That’s four confirmed tools in 30 seconds of reading.

When the list gets long, let AI do the heavy lifting

Some companies have 50+ subprocessors listed. Don’t torture yourself scrolling through all of them.

Copy the entire list and paste it into ChatGPT or Claude with a prompt like: “Here’s a list of subprocessors from a company’s Trust Center. Group them by function (infrastructure, analytics, security, communication, etc.) and tell me what each one does. Highlight any interesting patterns.”

You’ll get a clean breakdown without the eye strain.

Where to find these lists:

• Google “[company name] subprocessors”
• Look for links labeled “Trust Center,” “Security,” or “Privacy” in the website footer
• Check their privacy policy, sometimes the list is buried at the bottom

Not every company publishes one. But when they do, it’s one of the most honest signals you’ll find. No guessing, no inference, just a list of vendors they’ve contractually committed to using.

8) Analyze historical job postings

When a company hires for someone technical, they’ll often list the exact technologies that person will be using in the job. That part is obvious.

The problem is that many job postings turn into a buzzword soup. You’ll see things like “must know AWS, Google Cloud, Oracle Cloud, Kafka, Splunk, Elasticsearch, Grafana,” all in one paragraph. That doesn’t mean they actually use all of those day to day. Sometimes it’s aspirational. Sometimes it’s copy-pasted. Sometimes it’s just HR hedging.

So how do you figure out what they really use?

One simple trick is frequency. If a company mentions Splunk or Elasticsearch in most of their backend job postings, across teams and locations, that’s a strong signal those tools are actually part of the stack. If something only shows up once or twice, it’s probably optional, legacy, or team-specific.

To do this, you need to collect at least 8-10 job postings or, you need access to a lot of job postings over time. And that’s where things usually break down, because most companies (outside of Fortune 500 companies) usually just have 1 or 2 job postings that are semi-related to yours, and old listings get taken down from LinkedIn and company career pages.

Enter one of my favorite tools: the Wayback Machine.

The Wayback Machine archives old versions of web pages, including job listings and career search pages. If you paste a company’s jobs URL into it, you can often see years of historical postings that no longer exist publicly.

Here’s what you can do:

1. Take the main jobs search page for a company you’re interested in, paste it into the Wayback Machine, and browse snapshots going back years
2. Open old postings that are no longer live
3. Collect the technologies mentioned across many roles and time periods

The above is an example of a screenshot on what the Stripe careers page looked like in a prior snapshot in 2025. You can click on any of the job postings that you deem relevant, and it’ll show you what it looked like on that date.

At that point, you don’t need to manually read everything. Copy the text from multiple postings, paste it into ChatGPT, and ask it to extract and count technology mentions. Patterns jump out very quickly.

If Kafka, Elasticsearch, and Grafana show up everywhere, that’s probably the real stack. If Oracle Cloud shows up once in a single posting from three years ago, you can safely ignore it.

This works especially well for large companies that hire continuously. Their job postings are one of the most honest, long-term signals of what they actually run in production.

Conclusion

If you want surface level, sure, go ahead and subscribe to Wappalyzer.

But if you want actual tech intelligence, here’s the path:

1. Look at network calls directly
2. Check the Content Security Policy headers
3. Inspect DNS records
4. Read the tech signals in job postings (including historical ones)
5. Enumerate subdomains
6. Look up those subdomains to find cloud providers
7. Check subprocessor lists and Trust Centers
8. Browse real DNS traffic logs

You don’t need to pay. You don’t need to be an engineer. And you will routinely find more accurate and detailed stack insights than the paid scanners ever deliver.

The paid tools scrape the surface and call it a day. They see cookies and front-end libraries and stop there. Meanwhile, the real stack lives in DNS records, CSP headers, job postings, and traffic logs that they never bother to check.

Every technique in this guide is free. Most take less than five minutes. And when you combine a few of them together, you’ll know more about a company’s infrastructure than their own sales reps do.