How anVendor works — and why our technology is unique

Every technology-intelligence tool answers the same question: does this company use X? Almost all of them answer it by looking at the company. anVendor looks at the other side of the relationship — the vendor.

The two approaches everyone else uses

Site analysis. BuiltWith, Wappalyzer and similar tools read a company's public website: the scripts it loads, the tags it fires, its headers and DNS. Within that scope they are accurate and fast. But the scope is the marketing site's front end — the thinnest, most public slice of a company's software footprint. It says nothing about the tools people log into every morning.

Vacancy analysis. TheirStack and similar tools mine job listings for tool names. That is a genuine signal about direction of travel. It is not a signal about spend. A job ad names what a company wants to hire for: a stack one team prefers, a system they are migrating away from, a requirement copied from a template. It is intent, not billing.

Both are inference from the customer's own public surface. When a company doesn't advertise a tool on its website and isn't hiring for it, both go quiet — even if the company has been paying for it for years.

What anVendor does instead

We analyze vendor services alongside publicly available information, and look for the signs that a specific company holds an account with a specific service. The evidence sits on the vendor's side of the relationship, not the customer's.

We don't describe the method — it is what makes the product, and it is a trade secret. We are precise about the boundary instead. It operates only on information we are lawfully entitled to process. It never reaches into private, password-protected, or otherwise access-restricted systems. It circumvents no technical protection and intercepts nothing. There is no browser extension, no SDK, and no tracking script watching what anyone does online — not ours, and no one else's data obtained that way.

What that changes

• Software behind the login becomes visible. Design tools, documents, CRM, HR, ticketing, code hosting, meetings, storage. For most companies this is the larger part of the software budget, and none of it touches the marketing site.
• A subscription, not a snippet. A tag on a page proves a script was installed once — possibly years ago, possibly by an agency that has since moved on. An account is a live relationship with the vendor, which is much closer to a line on the invoice.
• Depth, not just presence. Because the evidence sits at account level, a result can show how far a tool has actually spread inside a company rather than a bare yes/no. Two seats and a company-wide rollout are entirely different conversations.
• It runs in both directions. Company → the subscriptions it holds, and service → the companies holding it. The same evidence, read either way round.

What we don't claim

Absence of evidence is not evidence of absence. Where a vendor's service offers no public sign, we report nothing rather than guess — so a service missing from a result means no evidence found, not not used.

A result is a strong indicator, not a contract. Treat it as the reason to ask a better question, not as a number to build a forecast on. Coverage runs to more than a hundred business services and keeps growing, weighted toward the categories B2B teams actually sell into rather than every consumer app in existence. And data ages, which is why every cached result carries its date and a fresh scan is one click away.

Where each tool fits

This isn't either/or. Use site analysis for what is genuinely on the website: analytics, ad tech, CDN, front-end frameworks. Use vacancy data for where a company says it is heading. Use anVendor for what it is subscribed to today, including everything behind the login. Serious research uses more than one lens — we would just rather you knew which lens each one is.