How do you find out what a competitor is built on?

Best move: read the signatures the site emits, not the tools page or the job listings.

Why it works: every framework, CDN, and AI SDK leaves a trail in loaded code, response headers, and DNS. Those fingerprints survive minification and outlast any marketing claim.

Key takeaways

• Detecting a competitor’s stack means matching signatures across four surfaces: loaded scripts, HTTP headers, DNS and TLS records, and runtime API hostnames.
• The tech-stack layer (frameworks, CMS, analytics) is commoditized. The differentiator is correlating it with infrastructure and the AI backend.
• Infrastructure fingerprints (ASN, CDN, nameservers, MX, TLS issuer and SANs) reveal hosting and email vendor choices a marketing page never states.
• AI-stack detection (model providers, SDKs, vector stores, orchestration) tells you whether a competitor ships AI or only talks about it.
• A static crawl plus optional JS render misses fully server-side or proxied components, and an honest teardown reports those gaps rather than guessing.

Where does a website reveal what it runs on?

Four surfaces, and each is public. First, the loaded assets: script src attributes, bundle names, and inline globals name the framework (Next.js sets __NEXT_DATA__ and _buildManifest), the analytics (gtag, analytics.js), and the widgets. Second, response headers: Server, X-Powered-By, Via, and cookie names leak the runtime and the CDN. Third, DNS and TLS: the A record’s ASN maps to the hosting org, the nameservers name the DNS provider, MX records name the email vendor, and the certificate’s issuer and SANs expose more hostnames. Fourth, network calls: the API hostnames a page hits at runtime name the backend services, from Stripe to Pinecone.

Any one surface is a lead. Two that agree make a confident match. You read all four without a login, because a public site has to serve this to every visitor’s browser. The catch: a site can proxy calls through its own domain, which hides the third-party hostname behind a first-party path. That is where a single-surface tool guesses and a correlated one flags the gap.

Which signals matter more than the tech stack?

The tech stack is the layer everyone can read, so it is the layer worth the least. BuiltWith, Wappalyzer, and TheirStack all mirror it, and the detections converge. What separates a real teardown is the layers that only correlation assembles.

Infrastructure is the first: the ASN and hosting org tell you whether a competitor runs on their own metal, a hyperscaler, or a PaaS, and the CDN choice hints at scale and budget. Nameservers, MX records, and the email provider reveal the operations stack behind the marketing site. TLS certificate SANs often leak staging hosts and sibling properties. The second is firmographics fused to the technical picture: company, vertical, and contacts sitting next to the stack, so a signal has context. The third, and the one nobody reads well, is the AI backend, which tells you what they are building next, not what they shipped last year.

Read alone, each layer is a fact. Read together, they form a thesis: this company runs lean on a PaaS, ships real AI on Anthropic and Pinecone, and has no security headers, so they are early and moving fast. That thesis is the deliverable, and you cannot get it from a single-layer scan.

How do you tell if a competitor ships AI or only talks about it?

Read the backend, not the homepage. Most AI-readiness checks scan the landing page for the word “AI” and look for an llms.txt file. That rewards marketing over engineering. The real tells are harder to fake and pointless to fake.

Model providers show up as SDK imports and API hostnames: api.anthropic.com, api.openai.com, the Vercel AI SDK’s client code. Vector stores (Pinecone, Weaviate, Qdrant, Chroma, Milvus) each ship recognizable client libraries and call named endpoints. Orchestration frameworks (LangChain, LlamaIndex, Haystack, CrewAI) carry distinct package signatures. LLM observability (Helicone, LangSmith, Langfuse) proxies requests through named hosts. An MCP endpoint or a .well-known AI file is a strong, deliberate signal.

Count the distinct signal groups a site hits and you get a readiness score, not a vibe. A verdict follows: shipping when the backend fingerprints are present, experimenting when the signals are thin or only an llms.txt exists, none when nothing loads. The honest limit: a competitor can run all of this server-side, behind a proxy, and a static crawl will not see the outbound calls. When that happens, report “not observable from the client” rather than a clean “none.” Absence of a signal is not proof of absence.

What can a teardown not see?

An honest teardown states its blind spots. A static HTML crawl reads server-rendered markup and headers, but it cannot see anything that only initializes in the browser. Adding a JS render step recovers client-only widgets and lazy-loaded scripts, at the cost of time. Even then, three things stay hidden.

First, fully server-side logic: a backend that calls OpenAI from its own servers and returns finished HTML emits no client-visible signature. Second, proxied services: when a site routes third-party APIs through its own domain, the vendor hostname disappears behind a first-party path. Third, anything gated behind a login, since a keyless crawl only sees the public surface.

This is why a single confident-sounding detection is less trustworthy than a correlated one that reports its coverage. The right move is to name the gap. If the tech stack is clear but the AI backend is silent, the finding is “no client-observable AI,” which is different from “no AI.” A teardown that hides its limits will overstate a competitor’s simplicity and hand you the wrong strategy. Report what you reached, report what you could not, and let the reader weigh both.

How is this different from BuiltWith or Wappalyzer?

Those tools do one thing well: they mirror the tech-stack layer. Wappalyzer and BuiltWith maintain large detection rule sets and answer “what CMS, what analytics, what framework.” TheirStack and SimilarWeb add traffic and firmographic corpora on top. For infrastructure, Censys, Shodan, IPinfo, and DomainTools each own a slice: certificates, open ports, IP data, WHOIS history. For firmographics, Apollo, ZoomInfo, and Clearbit sell contact and company records. Each is strong inside its lane.

The gap is correlation. To assemble the full picture with these tools, you run five queries against five products and stitch the answers yourself, and the stitch is where the insight lives. An agent cannot cheaply get correlation from five separate services, because the join is manual and the layers do not share a key.

A single call that returns tech, infrastructure, firmographics, AI backend, and security together, already joined, is a different product. The moat is not a bigger corpus. It is fusion, plus the AI-stack depth nobody else reads, delivered keyless over MCP so an agent can call it inside one request. Their moats are real, and they are single-layer. This is the five-layer version.

Bassethound perspective

Competitive teardowns have a bad habit: they stop at the tech stack because that layer is easy to read. It is also the commoditized layer, and reading it well proves nothing. Anyone can tell you a competitor runs Next.js on Vercel. The question that moves a strategy is what they are building next, and that lives in the AI backend and the infrastructure choices, not the framework.

Our conviction: fusion is the moat, not fan-out. Five separate MCP servers can each answer one layer, but the correlation between them is where the thesis forms, and an agent cannot cheaply reconstruct it by hand. We also read the axis nobody else reads. Deep AI-stack detection (model providers, vector stores, orchestration, observability) tells you whether a competitor ships or talks. Everyone else’s AI-readiness is a homepage keyword scan plus an llms.txt check. That is the shallow end. And we do it keyless, because we own the crawl, so an agent connects and asks without a key or a stored session. Read the stack, the infrastructure, and the AI backend together, in one call, and be honest about what a static crawl cannot reach. That is a teardown you can act on.

Sources

• MDN HTTP headers reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
• Model Context Protocol: https://modelcontextprotocol.io
• llms.txt specification: https://llmstxt.org
• Pinecone documentation: https://docs.pinecone.io
• Mozilla SSL configuration generator: https://ssl-config.mozilla.org