Why isn't tech-stack detection enough to profile a company?

Best move: treat the tech stack as one input to a profile, not the profile itself.

Why it works: a framework list tells you how a site is built, not who the company is, how they run their infrastructure, or whether they ship AI. Those live in other layers, and the answer you want sits in the correlation between them.

Key takeaways

• Tech-stack detection covers one layer: frameworks, CMS, analytics, widgets, payments. It is the commoditized layer, mirrored cheaply by many tools.
• A framework list tells you nothing about the company’s vertical, contacts, hosting org, email-auth posture, or whether it runs a real AI backend.
• Buying signals come from correlation across layers, not from any single detection.
• AI-readiness is the axis single-layer scanners miss, because it lives in backend fingerprints, not the homepage’s CMS.
• Bassethound returns all five layers correlated in one call, so the stack becomes evidence rather than the whole answer.

What does a tech-stack scan tell you?

A tech-stack scan reads the front end and names what it loads. Frameworks (React, Vue, Next.js), the CMS (WordPress, Shopify, Webflow), analytics (GA4, Segment), chat widgets, payment SDKs, ecommerce platforms. Each detection carries a category, a version when it leaks, a confidence, and the evidence that triggered it. This is real signal. It tells you how the site is built and how mature the front-end engineering is. BuiltWith and Wappalyzer have sold this for years, and they do it well. The catch is scope. A stack scan answers one question: what technologies does this page load? It does not answer who the company is, where they host, whether their email is authenticated, or whether there is an AI system behind the marketing copy. Those answers live in different layers of evidence. Treating the framework list as a company profile is a category error. It is like reading a car’s tire brand and calling it a spec sheet: real information at the wrong scope. Bassethound returns this layer as primary_stack inside a larger dossier, so you get the detection and the context it sits in.

What does tech-stack detection leave out?

Four things, and they are the ones you want. Infrastructure: the IP, ASN, hosting org, CDN, nameservers, MX records, email provider, and the TLS certificate with its expiry. A stack scan does not touch DNS or certs. Firmographics: company name, vertical, description, contacts, social profiles, structured data. The framework tells you nothing about the business. AI-readiness: model providers, AI SDKs, orchestration frameworks, vector stores, LLM observability, llms.txt, MCP endpoints. This is backend fingerprinting, invisible to a homepage CMS check. Security: the header grade (HSTS, CSP, X-Frame-Options, and the rest) plus the TLS grade. A tech-stack list reports a modern framework on a site with no security headers and a certificate that expires in thirty days, and flags neither. Each of these is a separate axis of truth about the company. Miss them and you are profiling a silhouette. Tech-stack detection is not wrong, just partial. The missing layers carry most of the signal a sales, security, or research workflow needs.

Why does correlation across layers beat five separate lookups?

Because the answer you want is a relationship between layers, and relationships do not survive being split across vendors. Consider intent. A company running Anthropic’s SDK (AI layer) on Vercel (infrastructure) with a fresh llms.txt (AI layer) and a valid DMARC record (infrastructure) is shipping and reachable. That verdict comes from reading the layers together, in the same pass, on the same fetch. Buy five tools and you get five lists on five clocks with five auth flows, and you still reconcile them by hand. You also pay five times, and each vendor renders the same page again. Fan-out is the expensive way to get less. An agent calling five MCP servers cannot cheaply reconstruct a correlation the servers never computed. This is the core reason single-layer detection loses to fusion. The corpus stops being the moat once the crawl is commoditized. The moat is the join. Bassethound fetches once and returns primary_stack, ai_readiness, security_grade, and an icp_signal (hot, warm, cold) already fused, so the agent gets a decision, not a pile of fragments.

How do you tell a real AI backend from a marketing claim?

You read the stack, not the headline. Marketing pages say “AI-powered” for free. A real AI backend leaves a trail: a model provider’s SDK in the bundle, a call to api.anthropic.com or api.openai.com, an orchestration import (LangChain, LlamaIndex), a vector-store client (Pinecone, Weaviate, Qdrant), or an observability hook (Helicone, Langfuse, LangSmith). Bassethound groups these signals and scores ai_readiness as the count of distinct signal groups hit, out of six, capped at one. The verdict follows: shipping, experimenting, or none. This is the axis single-layer scanners miss, because none of it lives in the CMS or the analytics tag. It lives in backend fingerprints. A vector store is a better tell than any claim, because it is expensive to stand up and pointless to fake. Be honest about the limits. A server-side model call behind a proxy leaves no client-side signal, and a static crawl can miss it. Bassethound renders JavaScript when the signals call for it and reports what it could not reach, so a low score reads as “not detected here,” not “definitely absent.”

When is a tech-stack list enough on its own?

Sometimes it is, and you should not over-buy. If your only question is “what CMS does this run” or “does this site use Shopify,” a single-layer scan answers it and you are done. Migration research, plugin compatibility checks, and competitive front-end teardowns often need one layer. The gap opens the moment your question is about the company rather than the page. “Should we prospect them” needs firmographics and AI-readiness. “Is their email spoofable” needs infrastructure and security. “Do they ship real AI” needs the backend fingerprint. Those are join questions, and a framework list cannot answer a join. The rule of thumb: if the decision depends on one attribute of the page, one layer is enough. If it depends on how attributes relate across the company’s stack, infra, and business, you need the correlated dossier. Bassethound serves both from one endpoint. The fast profile returns deterministic detection in one to three seconds, keyless. The standard and deep profiles add the layers when the question demands them. You pick the depth per call, not per subscription.

Bassethound perspective

The industry sells single-layer detection as company intelligence, and that is the thing we will not do. BuiltWith and Wappalyzer built good tech-stack products, and the tech-stack layer is now a commodity you can mirror cheaply. So we do not lead with it. A competitor would dispute this: the corpus stops being the moat once the crawl is commoditized, and fan-out is the expensive way to get less. An agent can wire up five MCP servers (one for tech, one for DNS, one for firmographics, one for AI, one for headers) and still not have the answer, because none of those servers computed the join. Correlation is the product. We fetch a domain once and return five layers already fused into primary_stack, ai_readiness, security_grade, and an icp_signal, in a single keyless call. The deep AI-stack layer is the unclaimed axis, and everyone else’s AI-readiness stops at the homepage and llms.txt. We read the backend. We are also honest about the edge: a proxied server-side component can hide from any crawler, and the dossier says so instead of guessing. Read the stack, not the story.

Sources

• Model Context Protocol: https://modelcontextprotocol.io
• llms.txt proposal: https://llmstxt.org
• MDN, HTTP headers reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
• IETF RFC 7489 (DMARC): https://datatracker.ietf.org/doc/html/rfc7489