DEV Community: Henley Wing

Jira vs Linear: Who's winning new customers?

Henley Wing — Thu, 07 May 2026 17:09:26 +0000

If you spend any time on tech Twitter or developer Reddit, you already know the script. Someone complains about Jira. Someone tells them to switch to Linear. A third person jumps in to defend Jira if you just configure it properly. Repeat weekly.

Plenty of opinions, very little data. So I went looking for the actual numbers, using adoption-signal data from Bloomberry, which tracks new customers through clickstream data - meaning when a new company-specific URL shows up (a new Atlassian Jira workspace URL, a new Linear team URL, and so on), it's logged as a new customer for that tool.

The dataset covers roughly a million company domains tracked between February 2025 and April 2026.

A quick definition before we get into it: when I say "customer," I mean any company that newly adopted the tool, whether on a free trial, free tier, or paid plan.

Here's what the numbers say.

Linear is catching Jira fast

Twelve months ago, this race was not close. Between February and April 2025, Jira picked up 2,225 new companies. Linear picked up 807. Jira was acquiring almost three times as many new customers each month, every month.

A year later, the gap has nearly disappeared. In February through April 2026, Linear added 1,351 new companies. Jira added 1,524. The two are now within 12% of each other, and the lines are heading in opposite directions:

Tool	Feb–Apr 2025	Feb–Apr 2026	YoY change
Linear	807	1,351	+67%
Jira	2,225	1,524	-32%

Linear added two-thirds more new customers in the most recent three-month window than the same window a year ago. Jira added roughly a third fewer. If both trends hold, Linear overtakes Jira on new customer acquisition within a quarter or two.

There is one important wrinkle on the Atlassian side. New Jira signups are dropping, but the number of existing Atlassian customers expanding the product across their organizations has held steady. The way to detect organizational expansion in clickstream data is by looking for SSO setup with Atlassian - when a company configures SSO, it usually means the tool is being deployed beyond a single team. That signal stayed roughly flat year-over-year, up about 4%, while new Jira customer signups dropped 32%.

This isn't the same as revenue expansion or net revenue retention - we're not measuring seat counts or contract value. But it is a useful leading indicator of organizational rollout. And the two trend lines, when you look at them together, are pointing in opposite directions: existing customers keep expanding their footprint while new customers are signing up at a slower rate.

That's consistent with what Atlassian's CFO has been telling Wall Street for a while now. Revenue growth is being driven by existing customers expanding seats, not by net-new logos. The Atlassian story isn't "the product is dying." It's "the funnel for new customers is slowing, and we're making it up by selling more to the people we already have."

Different customers, different sizes

The two products serve very different parts of the market, which becomes obvious as soon as you cut the data by company size. I joined the customer data with LinkedIn organization data to see how each customer base breaks down by headcount:

Company size	Linear %	Jira %
2–10	12.3%	9.2%
11–50	45.6%	38.1%
51–200	27.0%	28.4%
201–500	7.9%	11.7%
501–1,000	3.0%	5.1%
1,001–5,000	2.8%	5.1%
5,001–10,000	0.6%	1.0%
10,001+	0.9%	1.2%

Linear is concentrated in one specific band: companies with 11 to 200 employees. Almost three-quarters of Linear customers - 72.6% - sit in that range, and the 11-to-50 bucket alone accounts for 46% of the entire customer base. That single bucket is bigger than any equivalent bucket for Jira.

Jira's distribution is wider on every dimension. It has slightly fewer customers in the smallest segments, but consistently more share from 200 employees up. The clearest gap shows up in the 1,001-to-5,000 bucket, where Jira has 5.1% of customers and Linear has 2.8%. Jira's enterprise tail is roughly twice as long.

The short version: a 25-person engineering team is probably picking Linear. A 2,000-person engineering org is probably staying on Jira. The interesting fight is in the 200-to-500 zone, where the choice really does come down to the team's preferences, the existing tooling stack, and how much process the company has built up around the issue tracker.

The industry split

The size split tells one story; the industry split tells a related but distinct one. For each tool, I calculated the lift over baseline: how much more likely a company in a given sector is to use the tool than the average company across the dataset. A lift of 4x means a company in that sector is four times more likely to use the tool than the typical company.

Sector	Linear lift	Jira lift
Software development	4.6x	2.8x
Technology, information, internet	2.8x	1.3x
Computer and network security	2.6x	2.2x
Computer games	2.2x	2.8x
E-learning providers	2.0x	1.5x
IT services and consulting	1.5x	1.7x
Medical equipment manufacturing	below baseline	1.6x
Biotechnology research	below baseline	1.3x
Telecommunications	below baseline	1.2x
Insurance	below baseline	1.2x
Financial services	1.4x	1.3x

Both tools peak in software, but with very different intensities. Linear's lift in software development is 4.6x - much sharper than Jira's 2.8x. Linear's customer base is more concentrated in tech as a percentage. But because Jira is the bigger product overall, it actually has more software customers in absolute terms.

The more revealing rows are the ones near the bottom of the table. Medical equipment, biotech, telecom, insurance - these are sectors where Jira has real penetration and Linear is below baseline. The common thread across all of them is heavy compliance and audit requirements: regulated workflows, change-management documentation, audit trails, role-based permissions, the kind of features that take years to build properly. Atlassian has been building for that buyer for two decades. Linear, based on its public roadmap, has not been and isn't planning to.

You can describe each product's identity in one line. Linear is the issue tracker for software companies and adjacent tech. Jira is the issue tracker for software companies, adjacent tech, and every regulated industry that ships software.

Funding stage tells the same story from a different angle

The size and industry data line up neatly with funding stage. Among customers where I have funding-stage data, here's how each tool's customer base breaks down:

Funding stage	Linear %	Jira %	Linear / Jira
Early stage (seed, pre-seed, angel)	37.5%	27.7%	1.35x
Series A / B / C	25.6%	19.2%	1.33x
Series D+	2.5%	2.1%	1.19x
Post-IPO	2.4%	5.4%	0.44x
Private equity	4.1%	8.0%	0.51x
Debt / grant / non-equity	8.6%	14.2%	0.61x

Linear is the venture-backed-startup product. Two-thirds of Linear customers with funding data are at Series C or earlier. The early-stage cohort alone - seed, pre-seed, and angel-funded companies - makes up 37.5% of the customer base. This is exactly who Linear was built for, and it's exactly who is signing up.

Jira is the established-business product. Post-IPO companies are 2.3 times more concentrated in Jira's customer base than Linear's. PE-backed companies are 2x more concentrated. Even debt and grant-funded organizations - universities, nonprofits, public-sector adjacent groups - skew toward Jira by 1.6x.

This is the size cut and the industry cut viewed from a third angle, and they all paint the same picture. Linear's customer is a small, fast-growing, venture-backed company. Jira's customer is everyone else who needs an issue tracker - including a meaningful share of small companies, but also the big established ones that Linear hasn't reached.

Tell me your stack and I'll guess your tracker

This was the single most interesting cut in the analysis. If I tell you a company uses Linear, what's the rest of their stack likely to look like? And how does that compare to Jira?

To answer that, I calculated lift again, but this time within each tool's customer base: how much more likely a Linear (or Jira) customer is to also use a given tool, compared to the baseline rate across all companies in the dataset.

Tool	Linear lift	Jira lift
Intercom (customer messaging)	122x	50x
Sentry (error monitoring)	109x	51x
Amplitude (product analytics)	109x	45x
Chargebee (subscription billing)	103x	48x
Cloudflare Workers (edge compute)	94x	not in top 30
Retool (internal tools)	90x	41x
Vercel Pro (front-end deploy)	88x	32x
PagerDuty (incident response)	88x	not in top 30
Weights and Biases (ML experiments)	78x	not in top 30
Cursor (AI code editor)	73x	not in top 30
Microsoft 365	not in top 30	3.8x
Azure DevOps	not in top 30	19x
Salesforce CRM	not in top 30	21x
Salesforce Experience Cloud	not in top 30	37x

Linear customers live in the modern startup stack. Sentry, Amplitude, Chargebee, Vercel, Retool, PagerDuty, Intercom - these are the names you'd expect to see on a Y Combinator company's tools list. The lift values are striking. Intercom shows up at 122x baseline, Sentry at 109x, Chargebee at 103x. The same patterns are present in Jira's customer base, but at two to three times lower lift.

The AI-tooling signal is even sharper. Cursor at 73x, Weights and Biases at 78x, Claude at 37x. These are tools that have only been in widespread use for about 18 months, and Linear customers are picking them up at extraordinary rates relative to the rest of the market. Linear customers aren't just modern - they're early on the AI-coding curve.

Jira customers live in a different world. The same modern dev tools appear in Jira's top co-vendors too, but at notably lower lift. Jira's distinctive companions are the big enterprise platforms: Microsoft 365, Azure DevOps, Salesforce CRM, Salesforce Experience Cloud. None of those crack Linear's top 30.

The takeaway is simple. Show me what tools a company uses, and I can guess which issue tracker they picked. A company on Vercel + Cursor + Sentry + Amplitude is overwhelmingly going to be on Linear. A company on Microsoft 365 + Azure DevOps + Salesforce is overwhelmingly going to be on Jira. The two stacks barely overlap, even though both products in theory solve the same problem.

How they sell mirrors who they sell to

There's another dimension worth pulling apart: how the customers of each tool actually go to market themselves. Two simple proxies are useful here:

A public pricing page on a company's website is a signal of self-serve, product-led-growth motion. The company is saying you can decide whether to buy without talking to anyone first.
A "Get a Demo" or "Request Demo" CTA on the homepage is a signal of sales-led motion. The buyer can't price-shop or sign up; they have to talk to a salesperson before anything happens.

These signals are noisy. Some PLG companies don't publish pricing - Linear itself buries it pretty deep, ironically - and some enterprise companies do. The honest framing isn't "every Linear customer is PLG." It's: among the companies where we can detect a clear go-to-market signal, what's the ratio?

Customer base	Pricing page (PLG)	Demo CTA (sales-led)	Demo : Pricing ratio
Linear	2,589 (39%)	3,981 (61%)	1.54x
Jira	2,634 (30%)	6,106 (70%)	2.32x

Linear's customer base is meaningfully more PLG-leaning. 39% of Linear customers with a detected GTM signal have a public pricing page, versus 30% for Jira. Phrased the other way around, Jira's customer base is about 50% more sales-led than Linear's - a 2.32x demo-to-pricing ratio, against Linear's 1.54x.

This tracks with everything else. Linear's customers are smaller and earlier stage, often selling to other developers and product managers who want to evaluate quickly without having to sit through a discovery call. Jira's customers are larger and more enterprise, often selling complex products on bigger contracts where buyers expect a sales motion. The same forces that produced "Linear customers use Stripe and Vercel; Jira customers use Salesforce and Microsoft 365" also produced "Linear customers ship pricing pages; Jira customers ship demo CTAs." It's the same underlying fact viewed through a different lens.

And then there's Monday

The Linear vs. Jira fight is the loud one in the project management space, but it's not the only race in the market. So I ran the same time-series analysis on Monday, which spends a fortune on TV and YouTube ads telling teams their tool will fix everything. The result was striking.

Monday's new customer acquisition has been in steady decline for the entire 14 months I tracked. Comparing March-April 2025 to March-April 2026, Monday went from 396 new companies to 235. That's a 41% drop year-over-year - sharper than Jira's 32% decline over the same window. December 2025 was Monday's worst month in the entire dataset, at just 83 new companies.

This isn't only what the third-party data shows. It's also what Monday's own management is telling investors. On the Q4 2025 earnings call, co-CEO Roy Mann described Monday's self-serve channels as "choppy," with persistently higher customer acquisition costs and lower returns in the SMB segment. The company told Wall Street not to expect any improvement in no-touch performance marketing through 2026. They withdrew their previously communicated 2027 targets. The stock dropped 13% on the report.

So when the data shows Monday's new business customer acquisition declining 41% year-over-year, with December 2025 marking their lowest month in the dataset, it's not a noisy signal. The company's own CEO is saying out loud, on an earnings call, that the SMB self-serve funnel is broken.

What does it all mean

For Linear, the momentum is real and broad-based. They own the modern, AI-era startup cohort, which happens to be the fastest-growing one. The harder question is what comes next. To keep growing at this pace, Linear needs to crack regulated industries or move up-market into 500-plus-employee organizations where Jira is entrenched. Both are hard. The regulated-industry play takes years of compliance work that doesn't show up in feature velocity. The up-market play means selling to procurement and IT departments that have been on Jira for a decade and have built every internal process around it.

For Atlassian, the regulated-industry moat is real and durable. Medical device companies do not switch issue trackers because of a viral Twitter thread. But losing the early-stage tech-startup funnel is a real long-term problem. Today's Series A is tomorrow's Series D, and those companies will carry Linear with them as they scale. The size-and-funding data isn't just a snapshot; it's a leading indicator of who the next decade's enterprise customers will be using.

For Monday, the decline is the most striking finding in the analysis. With their marketing budget and brand recognition, they had every opportunity to be the company that beat Linear in the SMB segment. Instead, their net-new customer growth is falling faster than any tool I tracked, and management is saying the funnel itself is broken. That's a different kind of problem from a tool that's losing a feature war. It suggests something has changed in how SMBs discover and choose project management software, and Monday's strategy was built for the old way.

The tools we pick early in a company's life tend to come with us as we grow. That's what makes the current moment interesting. The next decade of issue tracking is being decided right now, in the choices being made by 30-person startups.

Methodology: data comes from Bloomberry's technographic intelligence product, which detects new customers via clickstream signals - when a new Atlassian Jira workspace URL, Linear team URL, or equivalent product-specific URL appears, it's logged as a new customer for that tool. The same set of one million randomly sampled company domains was tracked for all products across 15 months (February 2025 to April 2026), so the comparisons are apples-to-apples. The "new Jira customer" count specifically captures companies that signed up for Jira as a project management tool - it does not include companies that originally signed up for Confluence or Jira Service Management and later expanded into Jira. Atlassian's true new-user flow is therefore larger than what's shown, but the methodology is identical across all 15 months, so the directional trends are valid.

Detecting paying Cloudflare customers (for fun and profit)

Henley Wing — Sun, 03 May 2026 14:48:57 +0000

A while back I got curious about whether you could tell the difference between a company paying Cloudflare serious money versus one that signed up for the free plan and forgot about it.

First thing I tried: response headers. Don’t bother. Cloudflare returns identical header names whether you’re running on Workers, sitting on an Enterprise contract, or using the free tier. That’s intentional – Cloudflare doesn’t want their product tier to leak through HTTP.

What isn’t intentional is everything else. Here’s a full walkthrough, ordered from weakest to strongest signal. Code samples are Python, but everything here is just DNS lookups and HTTP requests – translate to whatever language you want.

Baseline: Are They Even Using Cloudflare?

Before anything else you need to confirm you’re actually looking at a Cloudflare-proxied domain.

Cloudflare publishes their IP ranges publicly at cloudflare.com/ips. Resolve the domain’s A record, check if it falls inside those ranges. Or check the nameservers – Cloudflare customers using the full proxy will have ns1.cloudflare.com / ns2.cloudflare.com as their NS records.

def on_cloudflare(domain):
    a_records = dns_lookup_a(domain)
    if any(ip in cloudflare_ip_ranges for ip in a_records):
        return True

    ns_records = dns_lookup_ns(domain)
    return any("cloudflare" in ns for ns in ns_records)

Cloudflare Radar publishes the top million domains by traffic. DNS-resolve all of them against the Cloudflare IP list and you’ve got a large working dataset in under an hour.

The catch: this puts you at roughly 20% of the web. That’s a lot of personal blogs and parked domains. The signals below are about separating the serious customers from the noise.

Signal #1: Dashboard SSO TXT Record

Straightforward to check, surprisingly revealing.

When a company configures SSO for their Cloudflare dashboard login (wiring it into Okta, Azure AD, or another SAML identity provider), the setup process adds a TXT record to their DNS zone:

cloudflare_dashboard_sso=1111111

def has_dashboard_sso(domain):
    txt_records = dns_lookup_txt(domain)
    return any("cloudflare_dashboard_sso=" in r for r in txt_records)

This used to be locked to Enterprise. Cloudflare has since relaxed that, so it’s not a guaranteed paid signal anymore. But practically speaking: nobody running a hobby project or a small business on the free tier is going to spend their afternoon setting up a SAML connector. The configuration effort alone filters out the noise. Treat it as a soft signal of intentional, serious usage.

Fast to run across the full Radar million since it’s just a DNS query.

Signal #2: Cloudflare Email Products (MX Records)

Two completely different Cloudflare email products, both detectable via MX record inspection.

Email Routing is a free forwarding service. When enabled, Cloudflare replaces the domain’s MX records with their own mail servers. The pattern looks like this:

MX 52  route1.mx.cloudflare.net
MX 98  route2.mx.cloudflare.net
MX 91  route3.mx.cloudflare.net

Some zones use named variants instead: amir.mx.cloudflare.net, linda.mx.cloudflare.net, isaac.mx.cloudflare.net. Either way, the *.mx.cloudflare.net suffix is the tell. Since this is a free product it’s a weak signal on its own – but it does confirm the domain is actively managed in Cloudflare rather than just having DNS parked there.

Email Security (formerly Area 1) is the paid product. It’s an anti-phishing and email threat detection platform aimed squarely at enterprise security teams. When deployed in inline mode, it sits in front of the customer’s mail provider as the primary MX record, inspecting every inbound message before it reaches Google Workspace or Microsoft 365. The MX records point to Area 1’s inbound gateways rather than the customer’s mail provider directly – look for *.area1security.com or Cloudflare-owned inbound gateway hostnames.

def email_signals(domain):
    mx_records = dns_lookup_mx(domain)
    mx_hosts = [mx.lower() for mx in mx_records]
    return {
        "email_routing": any("mx.cloudflare.net" in mx for mx in mx_hosts),
        "email_security": any("area1security.com" in mx for mx in mx_hosts),
    }

Email Security is Enterprise territory – it’s a dedicated security product with per-seat pricing and a sales process. Seeing those MX records on a domain is a strong indicator of an Enterprise relationship.

Signal #3: Bot Defense Cookies

Passive signal – no probing needed, just inspect cookies on a normal response.

__cf_bm shows up when any of Cloudflare’s bot defense products are active: Bot Management (Enterprise-only), Super Bot Fight Mode (Pro+), or Bot Fight Mode (free). The cookie itself doesn’t tell you which tier, but its presence means someone has actively configured bot protection beyond the defaults.

_cfuvid appears when a site is using cf.unique_visitor_id inside a WAF Rate Limiting Rule to track unique visitors behind shared IPs (corporate NATs, etc.). Available on any plan, but writing custom rate limiting rules signals intentional configuration rather than a default install.

def cookie_signals(response):
    cookies = response.headers.get("set-cookie", "")
    return {
        "bot_management": "__cf_bm=" in cookies,
        "rate_limiting":  "_cfuvid=" in cookies,
    }

Neither cookie alone proves paid status. Together with other signals they help build the picture.

Signal #4: Custom Error Pages

A bit more involved, but one of the more reliable signals for Pro+ customers.

Cloudflare’s default error pages have consistent fingerprints you can match against:

"Attention Required! | Cloudflare" – WAF block page
_cf_chl_opt – challenge/CAPTCHA page
cf-error-details – diagnostic error pages

Pro plan and above lets customers replace these with custom error responses. Plenty of paying customers do this because Cloudflare’s default error page clashes with their brand.

The detection relies on a quirk: Cloudflare’s edge always writes the cf-ray header into every response. This Ray ID is generated at the edge – the customer’s origin server has no way of knowing it in advance. But when Cloudflare renders a custom error page, the edge also writes that same Ray ID into the response body.

So if the Ray ID from the response header appears in the body, and the body doesn’t match any default Cloudflare template, you’re looking at a custom error page from a paying customer.

def has_custom_error_page(response):
    if not (400 <= response.status < 600):
        return False
    if "cloudflare" not in response.headers.get("server", ""):
        return False

    ray_id = response.headers["cf-ray"].split("-")[0]
    if ray_id not in response.body:
        return False

    default_markers = [
        "Attention Required! | Cloudflare",
        "_cf_chl_opt",
        "cf-error-details",
        "__CF$cv$params",
        "/cdn-cgi/challenge-platform/scripts/jsd/main.js",
    ]
    return not any(m in response.body for m in default_markers)

One false positive trap: Cloudflare’s bot detection JS beacon also embeds the Ray ID in normal HTML responses. The default_markers exclusion list catches this.

To trigger the error page, hit a nonexistent API path: https://api.example.com/api/v1/zzzz_not_real. APIs reliably return 4xx on unknown paths, which triggers Cloudflare’s error rendering. Marketing sites require probing paths like /wp-admin or /.env – more aggressive and more likely to get your scanner flagged.

Running this against api.* subdomains at scale, the hits were Swiss classifieds platforms, central banks, major retailers, government agencies. Exactly the profile you’d expect for paid customers.

Signal #5: Cloudflare Access (Zero Trust)

Cloudflare Access gates any web application behind a login screen, typically used to protect internal tooling: Grafana dashboards, GitLab instances, Jenkins, internal admin panels. In 2026 it’s also being used to lock down MCP servers.

When you hit an Access-protected endpoint without a valid session, Cloudflare redirects to the customer’s team page on cloudflareaccess.com. That redirect is the signal.

def has_cloudflare_access(url):
    response = http_get(url, follow_redirects=False)
    if response.status not in (301, 302, 303, 307, 308):
        return False
    return "cloudflareaccess.com" in response.headers.get("location", "")

Internal tooling subdomains follow predictable patterns. For each domain, probe:

gitlab.<domain>
grafana.<domain>
jenkins.<domain>
internal.<domain>
admin.<domain>
wiki.<domain>
mcp.<domain>

Most won’t resolve. Check the ones that do. Access has a free tier (up to 50 users) so it’s not a hard Enterprise gate, but the engineering investment of configuring Access policies and integrating an identity provider correlates strongly with paid usage.

Signal #6: OV or EV TLS Certificates

This one requires understanding the three tiers of SSL certificate validation.

DV (domain-validated) is what every free service issues, including Cloudflare’s Universal SSL. The certificate authority just checks you control the domain. Takes seconds. The cert subject contains only CN=.

OV (organization-validated) requires the CA to verify your company is a real legal entity – business registration, phone verification, the works. Takes days. The company name is embedded in the cert subject: O=, L=, ST=, C=.

EV (extended validation) is OV with a deeper background check: jurisdiction, physical address, operational existence. Subject fields include businessCategory, serialNumber, jurisdictionCountryName. Used primarily in regulated industries where compliance frameworks mandate it.

The detection angle: Cloudflare cannot issue OV or EV certificates. Universal SSL is DV only. So if a domain resolves to Cloudflare IPs but its certificate is OV or EV, the customer purchased a commercial cert and uploaded it via Custom Certificates – a Business plan feature ($200/month minimum) used almost exclusively by Enterprise customers.

You can identify certificate tiers programmatically via the certificatePolicies OIDs:

2.23.140.1.2.1 – DV
2.23.140.1.2.2 – OV
2.23.140.1.1 – EV

def cert_tier(host):
    cert = fetch_tls_cert(host)
    if has_ev_subject_fields(cert) or "2.23.140.1.1" in cert.policy_oids:
        return "EV"
    if "O=" in cert.subject and "2.23.140.1.2.2" in cert.policy_oids:
        return "OV"
    return "DV"

def has_paid_cert(domain):
    if not any(ip in cloudflare_ip_ranges for ip in dns_lookup_a(domain)):
        return False
    return cert_tier(domain) in ("OV", "EV")

Testing against fendt.com: OV cert issued by DigiCert with O=AGCO GmbH, served from Cloudflare IPs. AGCO is a $14B multinational – the finding makes sense. OV/EV on a Cloudflare-served domain is one of the strongest single signals for Enterprise status.

Signal #7: Static IPs

By default, Cloudflare is anycast. A single IP like 104.21.3.47 could be serving thousands of completely unrelated domains simultaneously. The IP belongs to Cloudflare and is shared across their entire customer base.

Static IPs are an Enterprise-only feature where Cloudflare allocates IPs from their range exclusively to a single customer. Nothing else resolves to those IPs. Common in financial services and B2B SaaS where clients require stable IP addresses for firewall allowlisting.

Detection requires aggregate data. Build a frequency map across your full domain dataset:

def find_static_ip_candidates(all_cloudflare_domains):
    ip_to_domains = {}
    for domain in all_cloudflare_domains:
        for ip in dns_lookup_a(domain):
            if ip in cloudflare_ip_ranges:
                ip_to_domains.setdefault(ip, []).append(domain)

    # Anycast IPs serve thousands of domains
    # Static IPs serve 1-3 (apex, www, maybe a subdomain)
    return {
        ip: domains
        for ip, domains in ip_to_domains.items()
        if len(domains) <= 3
    }

Additional tell: Static IPs tend to be allocated in sequential blocks. If a single domain has two A records where only the third octet differs, and both are rare in your frequency map, that’s a strong Static IP signal.

Signal #8: Secondary DNS

One of the cleanest Enterprise signals and the easiest to detect.

Standard Cloudflare customers let Cloudflare host their DNS entirely – nameservers become ns1.cloudflare.com and ns2.cloudflare.com. Secondary DNS is a different model: the customer keeps their own primary DNS infrastructure and adds Cloudflare as a secondary authoritative server, receiving zone transfers via AXFR/IXFR as a resilient backup.

The NS records tell the story immediately. A Secondary DNS customer has both their own nameservers and Cloudflare’s secondary ones listed together:

ns1.company.com
ns2.company.com
ns0227.secondary.cloudflare.com
ns0022.secondary.cloudflare.com

The *.secondary.cloudflare.com pattern only ever appears for this product. The four-digit number is a per-customer or per-zone identifier.

def has_cloudflare_secondary_dns(domain):
    ns_records = dns_lookup_ns(domain)
    return any("secondary.cloudflare.com" in ns for ns in ns_records)

Per Cloudflare’s DNS feature matrix, Secondary DNS requires Enterprise plus the Foundation DNS add-on specifically – it’s not included in a standard Enterprise contract. That makes it a stronger indicator than most Enterprise features. Organizations running Secondary DNS have made a deliberate investment in DNS as critical infrastructure.

The IRS has it configured. Government agencies, central banks, and large financial institutions are the profile to expect when scanning for this.

Signal #9: Magic Transit (BGP)

Every other signal on this list works by inspecting a single domain. This one works differently – you’re looking at public BGP routing tables.

Magic Transit lets Enterprise customers route their own IP space through Cloudflare’s network. The customer brings IP prefixes they own (or lease), and Cloudflare announces those prefixes to the internet from AS13335. All traffic destined for those IPs flows through Cloudflare’s scrubbing infrastructure before reaching the customer’s network.

The detection approach: pull every prefix currently announced by AS13335, then WHOIS each one. Prefixes registered to non-Cloudflare organizations are Magic Transit customers.

Browse it manually first to validate the concept:

https://bgp.he.net/AS13335#_prefixes

For programmatic detection, RIPE stat is the most reliable data source:

import requests

def get_as13335_prefixes():
    r = requests.get(
        "https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS13335"
    )
    # Skip IPv6 -- Magic Transit customers are almost exclusively IPv4
    return [p for p in r.json()["data"]["prefixes"]
            if ":" not in p["prefix"]]

NOISE_PATTERNS = ["ip-ripe", "ip manager", "-mnt", "private customer"]
CLOUDFLARE_HANDLES = ["CLOUD14", "CLOUDF"]
NOISE_HANDLES = ["ripe", "arin", "apnic", "afrinic", "lacnic"]

def find_magic_transit_customers(prefixes):
    customers = []
    for p in prefixes:
        ip = p["prefix"].split("/")[0]
        org = whois_org(ip)  # ARIN RDAP with redirect following
        if not org or is_noise(org["name"], org["handle"]):
            continue
        customers.append({
            "prefix":  p["prefix"],
            "name":    org["name"],
            "bgpview": f"https://bgpview.io/prefix/{p['prefix']}",
        })
    return customers

Running this against the full AS13335 prefix list surfaces names like these:

Prefix	Organization
`23.227.37.0/24`	Shopify, Inc.
`199.68.19.0/24`	VISA International Service Association
`131.167.255.0/24`	Battelle Memorial Institute
`161.248.134.0/24`	Canadian Association of Blue Cross Plans
`203.15.65.0/24`	University of Sydney
`103.77.7.0/24`	FUJIFILM Data Management Solutions
`351.0/24`	Genetec
`2109`	Yardi Systems, Inc.

Three things to filter out:

ISPs and carriers use Magic Transit for their own DDoS protection – it’s actually one of Cloudflare’s largest use cases by traffic volume. Skip anything whose org name or netname contains ISP, TELECOM, CARRIER, or DATACENTER, or anything that has its own ASN with a large prefix count. Legitimate enterprise Magic Transit customers typically have one or two prefixes total and no BGP presence of their own.

WHOIS placeholders – entries showing as IP-RIPE, IP Manager, or handles ending in -MNT are administrative placeholders or IP broker records, not end customers.

IP leasing – some customers bring leased IP space rather than IPs they own outright. The WHOIS points to the leasing company (IPXO is common). The tell is mnt-lower: IPXO-MNT in the RIPE record.

After filtering, what remains is unambiguously Enterprise-tier. Magic Transit requires a dedicated sales engagement, a minimum committed bandwidth, and a manual BGP peering session with Cloudflare’s network team. You don’t stumble into it.

Watch Out For

Platform contamination. Hosting platforms like Kinsta run all customer sites through Cloudflare Enterprise by default. The tenant didn’t configure it, may not know it’s there, and isn’t a Cloudflare customer in any meaningful sense. This is part of why stacking paid signals matters – a Kinsta-hosted blog won’t have a custom error page or an OV cert or Cloudflare Access configured.

Scale carefully. Probing endpoints with WAF-triggering patterns (SQLi strings, common exploit paths) across thousands of domains will get your scanner blocked fast. Everything in this list can be detected with benign requests – non-existent paths, standard User-Agents, no exotic payloads.

Summary

Signal	Plan	Method
IP / NS check	Free	DNS lookup
Dashboard SSO TXT	Free (high friction)	DNS TXT lookup
Email Routing	Free	MX record lookup
Bot cookies (`__cf_bm`, `_cfuvid`)	Pro+	Passive HTTP
Custom error pages	Pro+ ($25/mo)	HTTP probe + body parse
Email Security (Area 1)	Enterprise	MX record lookup
Cloudflare Access	Free tier (strong proxy)	HTTP redirect check
OV/EV certificate	Business+ ($200/mo)	TLS cert inspection
Static IPs	Enterprise	Aggregate DNS map
Secondary DNS	Enterprise + Foundation DNS	NS record lookup
Magic Transit	Enterprise	BGP + WHOIS

None of these signals is definitive in isolation. Stack them and you get a surprisingly clear picture of where a company actually sits on the Cloudflare tier ladder – all from public data, no credentials required.

Spotted a signal I missed? Drop it in the comments.

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.