What We Learned From Our First 1,768 API Calls

DetectZeStack hit 1,768 total API calls this week. Not a massive number — but enough to see real patterns in how people use tech stack detection, what breaks, and what we had to build to fix it.

Here’s the unfiltered data from our first months in production.

The Numbers

Five users, two paying. That’s a 40% free-to-paid conversion rate — which sounds impressive until you remember the sample size is five. But the conversion happened because the product solves a real problem, not because of clever pricing psychology.

What People Are Scanning

Here are the most-scanned domains across all users:

github.com being #1 wasn’t surprising — it’s a natural test domain. stripe.com makes sense too: people want to see what the gold standard looks like.

The interesting ones are teikametrics.com and reboxcorp.com. These are real SaaS companies that someone is actively researching. That’s the competitive intelligence use case in action — scanning companies in specific verticals to understand their technology choices.

The 29.9% Cache Hit Rate Problem

Our cache hit rate is 29.9%. That means roughly 70% of requests trigger a fresh analysis — which takes 2–3 seconds of real HTTP fetching, DNS lookups, and TLS inspection.

Why so low? Two reasons:

1. Long-tail domains — Most requests are for unique domains that no one else has scanned. There’s very little overlap between users’ target lists.
2. Fresh data preference — Users doing competitive intelligence want current data, not last week’s cache. They’re checking if a company has migrated or adopted new tools.

A 30% cache hit rate isn’t bad for this use case. It means our cache TTL (24 hours) is working for the common domains but most requests are genuinely unique analyses. We’re not going to optimize for cache hits at the expense of data freshness.

The Partial Results Problem (and Fix)

This was our biggest learning. Some websites aggressively block automated HTTP requests — returning 403s, CAPTCHAs, or just timing out. Before our fix, these sites returned zero technologies detected.

But here’s the thing: even when a site blocks HTTP entirely, its DNS records and TLS certificates are still public. You can’t hide a CNAME pointing to cdn.cloudflare.net or a TLS cert issued by Let’s Encrypt.

So we built partial results. When HTTP analysis fails, the API falls back to DNS CNAME analysis and TLS certificate inspection. You get fewer technologies, but you get the infrastructure-level ones — CDN, cloud provider, PaaS — which are often the most valuable data points anyway.

{
  "url": "https://example-blocked-site.com",
  "domain": "example-blocked-site.com",
  "technologies": [
    {
      "name": "Cloudflare",
      "categories": ["CDN"],
      "confidence": 80
    },
    {
      "name": "Amazon Web Services",
      "categories": ["PaaS"],
      "confidence": 80
    }
  ],
  "scan_depth": "partial",
  "cached": false
}

The scan_depth: "partial" field tells you exactly what happened. Full means all four detection layers ran successfully. Partial means HTTP failed but DNS and TLS still returned results. Consumers of the API can decide how to handle each case.

The 2.4-Second Median Response Time

Our p50 latency is 2,454ms. That’s not fast by API standards, but tech detection is inherently slow: we’re making real HTTP requests to the target site, running DNS lookups, and inspecting TLS certificates.

The breakdown:

• HTTP fetch + analysis: ~2 seconds (includes following redirects, parsing HTML, checking headers)
• DNS CNAME lookup: ~100ms (2-second timeout, but usually fast)
• TLS certificate inspection: ~200ms
• Cache hits: ~5ms (when they hit, they’re instant)

The 15-second analysis timeout means worst-case is well-bounded. For batch use cases, the bulk endpoint processes multiple domains concurrently, so latency amortizes across the batch.

Most Common Technology Stacks Detected

Based on our scans, the most frequently encountered technologies include:

1. Cloudflare — Appears on a huge percentage of scanned sites. CDN dominance is real.
2. Google Analytics — Still ubiquitous, despite the GA4 migration complaints.
3. React — The most common frontend framework by a wide margin.
4. Next.js — Growing fast, especially in the SaaS companies our users scan.
5. WordPress — Still powers a significant chunk of the web, especially outside tech.

The pattern is clear: modern SaaS companies cluster around React/Next.js + Cloudflare + Stripe. That’s the “default stack” for funded startups in 2026.

What’s Next

Three things we’re focused on based on what the data is telling us:

1. Better partial results — Adding more DNS signatures. We currently have 100+ CNAME patterns but there are long-tail PaaS and CDN providers we’re missing.
2. Historical data — Users want to know when a company changed their stack, not just what it is today. We’re already caching results; surfacing the history is the next step.
3. Batch scanning improvements — Our highest-volume user does 960 calls per month. At that scale, batch efficiency and rate limiting UX matter a lot.

If you’re building something that needs tech stack data, we’d love to hear what patterns you see. The API is free to start with — 100 requests per month, no credit card.