How to Find a Competitor's Tech Stack: 9 Sources, Compared

Almost every guide to this question answers it with a browser extension. That gets you the analytics tag, the tag manager, the CDN and the chat widget in about thirty seconds, and it is genuinely useful. It is also, for most software companies, a small fraction of the stack and the fraction that matters least competitively.

The full picture comes from layering three kinds of source: what the browser can see, what the company is contractually obliged to disclose, and what it must describe precisely in order to hire.

1. 1Decide what the stack is going to tell you. Knowing they use a given database changes nothing on its own. Sizing their integration surface, judging whether they can serve a regulated buyer, or spotting a re-platform in progress are decisions. Pick one before you start.
2. 2Run a detection tool for the browser-visible layer. A detector or browser extension gives you the client-side picture in seconds: analytics, tag manager, CDN, front-end framework and support widget. Treat it as the first 20% of the answer rather than the answer.
3. 3Read the page yourself. Open view-source and the network tab and look at what actually loads. Detectors work from signatures and miss anything self-hosted, proxied or newly added, and the network tab shows you the request regardless.
4. 4Find the subprocessor list. Look for a trust centre, security page or DPA and open the subprocessor list. Most business vendors publish one and commit to updating it, because their own customers require notice of changes. It names hosting, email, support, analytics and payments in one place.
5. 5Read six months of engineering job ads. Job descriptions name the internal stack precisely, because the role depends on it. This is the only reliable public window into the backend, the data warehouse and the deployment tooling.
6. 6Check the DNS records. MX records reveal the email provider, CNAME records reveal the CDN and hosted subdomains, and TXT records carry the verification strings that several SaaS vendors require. All of it is public by design.
7. 7Date it and watch for the change. A stack list is a snapshot. What matters competitively is the change: a new payment provider, a new region, a migration mentioned in a job ad. Record the date and re-check quarterly.

A detection tool works by fingerprinting what a public page sends to your browser. That bounds what it can possibly know. Understanding the boundary is what stops you presenting a partial list as a complete one.

Two of the five layers are visible to a detector, and neither is the one that determines whether they can serve a regulated buyer or ship the integration your prospect is asking for.

A subprocessor is a third party that handles customer data on a vendor’s behalf. Business software vendors publish a list of theirs and commit to notifying customers before it changes, because their own enterprise customers and data protection agreements require exactly that. The result is a maintained, public, company-authored inventory of the vendors running their hosting, email, support, analytics and payments.

To find it, look for one of these on the competitor’s own site:

• A trust centre or security page, usually linked from the footer.
• The data processing agreement or DPA, which normally has a subprocessor annex.
• A privacy policy section headed “service providers” or “subprocessors”.
• A subprocessor change notification page, which some vendors publish as a subscribable feed because customers ask for it.

1. Technology detection tools

BuiltWith, Wappalyzer and WhatRuns install as browser extensions or run as a lookup. They are fast and free at low volume, and they are also the source most likely to be quietly wrong: detection lags removals, so a technology can sit in a profile after it has been taken off the site. Run two of them and treat any disagreement as a prompt to check yourself.

2. View source and the network tab

Open developer tools, reload the page, and read the network requests by domain. Every third-party domain is a vendor. This catches self-hosted, proxied and newly added tools that signature-based detection misses, and it takes about two minutes. Check the response headers too: server, CDN and framework hints frequently sit there in plain text.

3. Their trust centre or subprocessor list

Covered in full above. Start here for anything that handles customer data.

4. Engineering job postings

Read six months of their engineering, data and infrastructure roles. A job description has to be specific or the wrong candidates apply, so it names the languages, the database, the cloud provider, the warehouse and the deployment tooling directly. The change between postings is the real prize: a new language appearing across three roles is a migration you can see months before the product reflects it.

5. Engineering blog, talks and public repositories

Where a competitor has an engineering blog or speaks at conferences, you get architecture and the reasoning behind it in their own words, which is deeper than any inference. Their public repositories and the dependency files inside them are equally direct. For large engineering organisations this is the best source available and the one to start with.

6. Public DNS records

DNS is public by design. MX records name the email provider, CNAME records reveal the CDN and any hosted subdomains, and TXT records carry the domain-verification strings that many SaaS vendors require in order to activate an account. Together they identify a set of vendors no page-level detector will report.

7. Docs, API reference, status page and changelog

The API docs tell you the integration surface. The status page tells you how the system is decomposed, because components that fail separately are listed separately, and the incident history tells you where it is fragile. The changelog dates every capability they have shipped, which is the cleanest competitor feature tracking source that exists.

8. App store listing and privacy labels

Mobile app listings disclose data collection practices, and those disclosures name categories of SDK the app embeds. Release notes date each version. This is the only reliable window into a mobile stack.

9. Review sites and developer communities

The integrations tab on a review site shows what customers actually connect the product to, and the reviews show which integrations they wish existed. Community threads add the failure modes. Low reliability on its own, useful for confirming a hypothesis you formed elsewhere.

1. 1Confirm in the network tab. If a detector reports a technology and no request to it appears when you load the page, it has probably been removed. Detection profiles keep stale entries.
2. 2Check the marketing site against the product. The homepage and the logged-in application are frequently different stacks entirely. Anything you learn from a public page describes their marketing, not their product.
3. 3Prefer the company’s own statement. A subprocessor list, a job ad or an engineering post beats any inference, and it is quotable in an internal document without a caveat.
4. 4Date it. A stack list without a date is unusable within a quarter, and the visible layer changes fast enough that this is not a theoretical concern.

Everything on this page reads information that is published or sent to your browser on request, which is what public web pages are for. The line is sharper here than on most competitive research, so it is worth being explicit.

• Reading is fine. Loading a page and inspecting what it sends, querying public DNS, and reading published documents are all ordinary uses of public information.
• Probing is not. Scanning for vulnerabilities, attempting to reach anything behind authentication, or testing a system you have no permission to test moves you from research into computer misuse legislation. There is no competitive justification that covers it.
• Do not create an account under false pretences to inspect the product. Signing up to a competitor’s trial in your own name and company is a judgement call many companies make openly. Doing it under a fabricated identity is deception and usually a breach of their terms.
• Respect the terms you agreed to. If you do hold an account with them, its terms govern what you may do with what you see, including screenshots and benchmarks.

• Their actual architecture. How the pieces fit together is not public. Proxy: the status page component list, the API structure, and any conference talk they have given.
• What they spend on it. Cloud and tooling costs are not disclosed at that granularity. Proxy: hosting regions and the size of the infrastructure team from job ads, as an indication of scale.
• Technical debt and reliability. Nobody publishes their weak points. Proxy: the incident history on their status page, and review-site complaints mentioning performance or outages.
• What they are building next. Roadmaps are confidential. Proxy: new job specialisms, new subprocessors added, and new API endpoints appearing in documentation before they are announced.

Re-run the browser-visible check quarterly, and watch three things continuously instead: their changelog, their subprocessor notification page, and their engineering job ads. Those three announce a change rather than reflecting one after the fact, which is the difference between finding out in the same week and finding out from a prospect.

Record the result in a competitor teardown alongside the product picture, and use a feature comparison matrix when the question is really about capability gaps rather than technology.