Article
How to find any company's tech stack (without paying) - Bloomberry
bloomberry.com
Quoted on this wiki
Every place a page here uses this source, in the order the words come in it.
3) Analyze historical job postings “When a company hires for a role, they’ll often list the exact tools that person will be using. And this isn’t just engineering roles – sales ops postings mention CRMs, marketing roles mention automation platforms, data analyst postings mention BI tools. Every department leaks tech stack information when they hire.” The problem is that many job postings turn into 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 HR hedging.
Copy the text from multiple postings, paste it into ChatGPT, and ask it to extract and count technology mentions. If Kafka, Elasticsearch, and Grafana show up everywhere, that’s the real stack. If Oracle Cloud shows up once in a single posting from three years ago, you can safely ignore it. “A “Revenue Operations Manager” posting that mentions “HubSpot, Outreach, and Snowflake” tells you exactly what their sales and marketing stack looks like. A “Customer Success” posting mentioning “Gainsight” or “Vitally” tells you what CS platform they run.” 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 use.
How do you find out what technologies a company actually uses? And I’m not talking about just the frontend stuff, but the real stuff: their CRM, cloud providers, data infrastructure, etc. “But these tools often miss everything that doesn’t show up in a browser.” I organized 12 techniques from simplest to advanced. The first section requires zero technical skill – anyone can do it. The later sections use advanced technical methods for developers/engineers.
The link is usually in 99% of cases somewhere in the footer. For example, here’s the Trust Center link in Canva‘s homepage (labeled “Trust Centre”): “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.” 2) Check their status page
1) Read subprocessor lists and trust centers “Let’s start with the easiest trick in this entire guide: just read what companies are legally required to tell you.” If a company handles personal data (especially in the EU), 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” (ie using a tool like Vanta) or “Security Center” page.
Let’s start with the easiest trick in this entire guide: just read what companies are legally required to tell you. “If a company handles personal data (especially in the EU), 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” (ie using a tool like Vanta) or “Security Center” page.” What you’ll find here is gold: the actual vendors they pay money to. CRMs, cloud providers, analytics tools, payment processors, customer support platforms, marketing automation, email services – basically a receipt of their entire operational stack.
If a company handles personal data (especially in the EU), 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” (ie using a tool like Vanta) or “Security Center” page. “What you’ll find here is gold: the actual vendors they pay money to. CRMs, cloud providers, analytics tools, payment processors, customer support platforms, marketing automation, email services – basically a receipt of their entire operational stack.” If you’re in sales, this is the fastest way to find out whether a prospect uses a competitor’s product. If their subprocessor list says “Salesforce – CRM and customer data” then you know they’re using Salesforce as a CRM. If it says “Zendesk – customer support” then you know they’re probably not using Intercom. It’s that direct.
Where to find these lists: “Google “[company name] subprocessors”” Look for links labeled “Trust Center,” “Security,” or “Privacy” in the website footer
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
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” The link is usually in 99% of cases somewhere in the footer. For example, here’s the Trust Center link in Canva‘s homepage (labeled “Trust Centre”):
What you’ll find here is gold: the actual vendors they pay money to. CRMs, cloud providers, analytics tools, payment processors, customer support platforms, marketing automation, email services – basically a receipt of their entire operational stack. “If their subprocessor list says “Salesforce – CRM and customer data” then you know they’re using Salesforce as a CRM. If it says “Zendesk – customer support” then you know they’re probably not using Intercom. It’s that direct.” Tech startups especially love publishing Trust Centers because it signals to enterprise buyers that they take security seriously (well maybe “love” is too strong a word :). But it means they’ll openly list every SaaS product touching their infrastructure.
This is a sneaky but powerful technique: if you know a tool had a major outage on a specific date, you can search status pages for companies that reported issues on the same day and mentioned that tool by name. Suddenly you have a list of confirmed customers that no technographic database in the world would have caught. “To find a company’s status page, just Google “[company name] status page” or try status.company.com. Most mid-size and larger companies have one.” 3) Analyze historical job postings
2) Check their status page “Many companies run a public status page – usually at status.company.com or hosted on a service like Statuspage, Instatus, or Betteruptime. These pages are designed to show customers whether services are up or down. But if you look closer, they leak a surprising amount about what’s under the hood.” There are two things worth looking at:
The components list tells you about their infrastructure “Status pages usually break things down by component or service. The way a company structures these components tells you what cloud providers they use, how they separate environments, and what they consider critical infrastructure.” For example, here’s Dynatrace’s status page:
Incident history reveals hidden dependencies “When things break, companies often explain why – and that explanation frequently names the upstream vendor or tool that caused the problem.” This is especially useful for finding tools that are otherwise nearly impossible to detect. Security products like CrowdStrike, for example, don’t show up in DNS records, frontend JavaScript, or job postings. No scanner will ever find them.
3) Analyze historical job postings “When a company hires for a role, they’ll often list the exact tools that person will be using. And this isn’t just engineering roles – sales ops postings mention CRMs, marketing roles mention automation platforms, data analyst postings mention BI tools. Every department leaks tech stack information when they hire.” The problem is that many job postings turn into 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 HR hedging.
So how do you figure out what they really use? “Frequency. If Salesforce shows up in every sales and marketing posting, that’s their CRM. If Snowflake appears across data engineering and analytics roles, that’s their data warehouse. If something only shows up once, it’s probably optional, legacy, or team-specific.” To do this well, you need at least 8–10 job postings. And that’s where things usually break down – most companies only have a couple of active listings, and old ones get taken down from LinkedIn and career pages.
Frequency. If Salesforce shows up in every sales and marketing posting, that’s their CRM. If Snowflake appears across data engineering and analytics roles, that’s their data warehouse. If something only shows up once, it’s probably optional, legacy, or team-specific. “To do this well, you need at least 8–10 job postings.” Enter one of my favorite tools: the Wayback Machine.
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. Paste a company’s careers URL into it (*not* an individual job url) and you can browse snapshots going back years. Open old postings that are no longer live and collect the technologies mentioned across many roles and time periods.” The above is what the Stripe careers page looked like in a prior 2025 snapshot. You can click on any job posting and see exactly what it said on that date.
The other goldmine is the incident history. When things break, companies often explain why – and that explanation frequently names the upstream vendor or tool that caused the problem. “Security products like CrowdStrike, for example, don’t show up in DNS records, frontend JavaScript, or job postings. No scanner will ever find them.” But you know what happened on July 19, 2024 – CrowdStrike pushed a faulty update that took down systems worldwide. And when that happened, companies posted about it on their status pages.
When a company hires for a role, they’ll often list the exact tools that person will be using. And this isn’t just engineering roles – sales ops postings mention CRMs, marketing roles mention automation platforms, data analyst postings mention BI tools. Every department leaks tech stack information when they hire. “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 HR hedging.” So how do you figure out what they really use?
Quotes are verbatim and belong to their publishers. Where a quote has been translated, the original wording is kept below it.