How to Find Companies Using a Specific Software: The Free Method That Found 1,419 Verified Businesses

Most prospecting starts with a guess. You pick a company size, an industry code, a job title, a region, and you buy a list that matches the filter. Then you spend budget finding out whether the guess was any good.

There is a much stronger signal sitting in public, and almost nobody uses it. If what you sell replaces, extends, or fixes a hosted platform, then the businesses running that platform are provably your market. Not similar to your market. Running the exact thing you displace, today.

I built one of those lists using only free tools. It came out at 1,419 verified businesses, 1,132 of them with a working contact route, and the strongest channel ran at 99% precision. Total spend on tools: zero. I am walking through the entire build live on Tuesday, August 11 in Use Claude Code to Find Every Business Running the Software You Replace, and everyone who attends leaves with the Claude Code skill I packaged it into.

This post is the map of that method. Six stages, the number each stage produced, and the three places I got it wrong.

Why is a software trace a better signal than a firmographic filter?

Every prospecting database sells you the same thing: a filter over attributes. Headcount, revenue band, industry classification, technology "signals" inferred from job postings. Those are all proxies for the question you actually care about, which is whether this business has the problem you fix.

A software trace is not a proxy. When a business runs a hosted platform, that platform leaves physical evidence on the business's own public website. A script served from the vendor's content delivery network. A login path that only exists on that platform. A distinctive set of meta tags or a theme signature. A canonical hostname on the vendor's domain. None of that is inferred. It is either in the page source or it is not.

That difference matters more than it sounds. A firmographic filter gives you a population that might have the problem. A trace gives you a population that demonstrably runs the thing you replace. The first list needs qualifying before it is worth touching. The second list is already qualified on the only dimension that decides the deal.

The second advantage is that nobody can sell you the same list. Vendor databases track the technologies the vendor decided to track. If your displacement target is a mid-size platform, or you care about a specific tier or feature rather than the platform as a whole, no vendor has indexed that distinction. You have to go and measure it.

The four kinds of trace worth looking for

• Network traces. Assets loaded from the vendor's delivery network, a vendor-owned hostname in a canonical tag, or DNS records pointing at vendor infrastructure. Strong signal, easy to query, sometimes shared with unrelated products from the same vendor.

• Path traces. URLs that only exist because the platform generates them. Account paths, checkout paths, embedded widget routes. These tend to be the highest-coverage signal because the platform generates them for every customer whether the customer wants them or not.

• Markup traces. Generator meta tags, class-name conventions, structured data the platform emits. Cheap to detect, but often stripped by customers on custom themes, which quietly destroys your coverage.

• Certificate traces. When a platform provisions certificates for customer custom domains, those issuances land in public logs. This is the channel nearly nobody checks, and I come back to it below.

How do you find the fingerprint a platform leaves on customer sites?

Pick five or six businesses you already know run the platform. Load each one, read the raw source, and write down every string that looks vendor-specific: hostnames, script paths, meta tags, cookie names, URL patterns. You will end up with a dozen candidates in about twenty minutes.

Then throw most of them away, because the next step is the one that decides whether the whole project works.

The coverage test almost everyone skips

Two candidate fingerprints can look equally valid on your five known sites and behave completely differently at scale. In my run, two candidates from the same platform measured 89% coverage and 14% coverage. On the sample sites they looked identical. One of them would have handed me roughly a seventh of the market and I would have had no way of knowing.

The test is simple and it takes fifteen minutes. Assemble a control set of thirty to fifty businesses you can independently confirm are on the platform. Fetch each one and check which candidate fingerprints are present. Coverage is the percentage of your control set that carries the trace. That single number tells you which fingerprint to build the whole list on.

Two things I learned doing this:

• Path traces usually win. The highest-coverage fingerprint in my run was an account login path, present on 89% of the control set, because the platform generates it for every customer regardless of how heavily they customize the front end. Markup traces lost badly, because the customers most worth selling to are exactly the ones who customized their theme and stripped the generator tag.

• Coverage and precision are different numbers and you need both. A trace can appear on 95% of customers and also appear on hundreds of sites that are not customers. Measure how many of your control set carry it, and separately measure how many random hits turn out to be real. Optimizing one and ignoring the other is how you end up with either a small list or a dirty one.

Which search index can actually query the whole web?

This is where most people stop, because the obvious tools only answer the question one site at a time. Browser extensions and single-URL lookup tools tell you what one business runs. They cannot tell you every business that runs it. Those are different products solving different problems, and the free ones are almost all in the first category.

There are four families of index that can answer the many-sites question, and they have genuinely different capabilities.

Source-code search engines. These index the raw HTML, JavaScript, and CSS of a few hundred million pages and let you query any literal string in the source. That is the important part: you are not limited to technologies someone decided to catalogue. You can search a vendor script path, an analytics account identifier, a proprietary snippet, a theme signature. Coverage is a few hundred million pages rather than the whole web, so recall is capped, and results come back as raw domains with nothing attached.

General web search with path operators. If your fingerprint is a path rather than a code string, a plain search engine will often find it, because search engines index URLs. This is the cheapest channel to try and it scales further than people expect. It is also the channel where I measured the worst verification rate, which I will get to.

Open web-scale crawl archives. Common Crawl publishes multi-billion-page web archives that are free to access by anyone from anywhere, in raw response format, computed-metadata format, and extracted-plaintext format, with a queryable URL index. New crawls land several times a year. This is the deepest corpus available at no cost, and the reason nobody uses it for prospecting is that it takes real work: you are querying an index and pulling archive segments, not typing into a search box. If your fingerprint lives in a header or a link rather than the visible text, the computed-metadata format is the one you want.

Certificate transparency logs. Certificate Transparency is an ecosystem that makes certificate issuance publicly verifiable. Logs are append-only and tamper-proof, and domain owners, browsers, academics and anyone else can analyse and monitor them. More than two and a half billion certificates have been logged since 2013. Here is why that matters for prospecting: when a hosted platform provisions certificates for its customers' custom domains, every one of those provisions is a public, timestamped record naming the customer's domain. It is close to a customer roster, published by the certificate system rather than by the vendor, and it is free.

The precision spread between these channels is not small. The strongest channel in my run came in at 99% precision, which is a completely different working experience from a channel where more than half of your hits are wrong. Which one it was, and how I set it up, is the part I walk through step by step in Tuesday's session.

How do you pull thousands of hostnames out of tools that cap your output?

Every index caps you somewhere: results per query, results per page, queries per day, or credits per month. The cap is a product decision, not a data limit, and there are three legitimate ways around it.

Slice the query instead of paging it. If a tool returns 1,000 results per query, do not try to page to 10,000. Partition the query space instead. Add a second term, restrict by top-level domain, restrict by a date window, restrict by a co-occurring string. Ten narrow queries that each return 400 results beat one broad query truncated at 1,000, and the union is usually larger than the cap you were fighting.

Read the input schema before you spend a single credit. I burned a meaningful chunk of one channel's quota because I assumed a scraping actor's input field was called one thing when it was called another. The job ran, returned results shaped like success, and quietly searched for nothing useful. An API-budget decision in that same channel wasted 60% of its quota before I caught it. Send one job with a single query, read what comes back, confirm the field names against the documented schema, and only then scale.

Normalize to registrable domains immediately. Raw hits arrive as page URLs. One business can produce forty of them. Collapse every hit to its registrable domain before you count anything, or your list size is a fiction and you will pay to enrich the same company forty times.

Running the extraction across several channels in parallel is where an agent earns its keep. This is the same pattern I use for everything else in my stack, which I wrote up in how I run a team of AI agents across 14 products: one agent per channel, each writing to its own output file, then a merge step that dedupes across all of them.

How do you verify a hit is still a current customer?

This is the stage that separates a list from a scrape, and it is completely absent from every guide I read while researching this post.

An index tells you what a page looked like when the index last saw it. That could be last week or it could be eleven months ago. Businesses migrate. They churn. They redesign. A hit is a claim about the past, and outreach based on an unverified claim reads exactly like what it is.

In my run, only about 43% of hits from the biggest channel were still real customers. Think about what shipping that unverified would have meant: more than half the list receiving a message premised on a fact that stopped being true.

The verification step itself is not complicated:

1. Fetch the domain live. Not the cached copy the index gave you. The current page.

2. Look for the fingerprint again. If it is gone, the business is out, no matter how confident the index was.

3. Check that the site is actually alive. Parked domains, expired certificates, and holding pages all pass a naive string match and none of them is a business.

4. Record the date you verified. A verified list is a perishable asset. Six months from now, the same list is a guess again.

The tier test

There is a refinement here that changes who you talk to. On most hosted platforms, the free tier and the paid tiers leave slightly different traces: a branded footer, a vendor subdomain instead of a custom domain, a feature that only exists above a certain price point. Detecting that difference costs one extra check per domain and splits your list into people paying the vendor money and people who are not.

That distinction matters more than list size does. A business already paying for the category has proven it will pay for the category. That is the single most useful thing you can know before you write the first sentence of an email.

How do you turn a domain list into contact routes?

A list of 1,419 domains is not a list of 1,419 businesses you can reach. Getting from one to the other took an eight-step protocol and produced 1,132 reachable businesses, which is 80%.

The pattern that mattered: the obvious enrichment approach worked on the easy majority and then flatlined. The step I added to recover the leftovers found routes for 57% of the missing set, where the obvious approach had managed 4% on that same set. Enrichment is not one technique applied uniformly. It is a cascade, where each pass is aimed at the specific reason the previous pass failed.

And here is the mistake I keep telling people about, because it is the kind that hides. I used a pattern match to classify a certain type of page, and one overly greedy word in that pattern wrongly labelled 213 out of 311 pages. Two thirds of that segment, silently misfiled. Nothing errored. The counts looked plausible. I only found it because I hand-checked a random sample of twenty rows against the live pages.

So build the sample check into the process rather than treating it as optional. Twenty rows, checked by a human, at every stage that transforms the data. It costs ten minutes and it is the only thing standing between you and a confidently wrong list.

If you want the enrichment cascade and the classification patterns as working code rather than description, that is exactly what the Reinventing AI Accelerator is for. Members get the skill from this session plus the full library of apps, tools and agents from every past session, and the live sessions are included.

How do you rank the list so you contact the right ones first?

Verification tells you a business runs the platform. Ranking tells you which ones have your problem right now, and it is the difference between an 80% reachable list and an actual pipeline.

Look for public evidence of the pain, not for size. Depending on what you sell, that might be a support or status page showing the limitation you remove, a job posting for the role your product makes unnecessary, a pricing page that reveals which tier they are on, or a visible workaround they have built because the platform does not do the thing.

The counter-intuitive part is that the biggest businesses on your list are usually the worst first targets. They have the most invested in the incumbent, the longest procurement path, and the most people who would have to agree. The businesses worth contacting first are the ones showing strain against the platform's limits: recently upgraded, visibly working around a gap, or running the exact configuration where the incumbent falls over. Rank on evidence of friction, not on headcount.

What this method does not do

Three honest limits, because the guides that skip these are the ones that get people in trouble.

A list is not permission. Everything above is discovery. It tells you who to talk to. It does not tell you that you are allowed to email them, and the rules for that depend on where the recipient is, not where you are. Sort out your own compliance position before the first send. I am not going to pretend a verified list changes that calculation, because it does not.

Finding buyers is not converting them. This method produces a list. It does not write your positioning, and a precisely targeted message to the wrong offer still fails. I can show you exactly how the list was built and what it contained. I cannot show you a conversion rate, because the honest answer is that the outreach half is a separate discipline.

The list decays. Businesses churn off platforms every month. A list verified today is meaningfully stale in a quarter and largely fiction in a year. The value is not the spreadsheet, it is the repeatable process that regenerates the spreadsheet. Which is exactly why I package this kind of work as a system rather than a one-time effort, a distinction I wrote about in why I stopped buying prompt packs and built systems instead.

Where Claude Code fits in all of this

None of the six stages is intellectually hard. All six are tedious, and they are tedious in the specific way that agents are good at: fetch a few thousand pages, apply a rule, write a row, report the aggregate.

What makes it worth packaging rather than re-prompting is that the method has standing rules. Always dedupe to registrable domain. Always verify live before counting. Always hand-check twenty rows. Never trust a field name you have not read in the schema. Those rules belong somewhere durable, not in whatever you happened to type that morning.

That is what Claude Code skills are for. A skill is a folder with an instruction file, and unlike instructions you keep in your project memory file, a skill's body loads only when it is actually used, so a long procedure costs almost nothing until you invoke it. The entire six-stage method fits in one, which is why the session ships as a skill rather than a document. It plugs into the same scheduled setup that runs the rest of my marketing, which I described in the system I run every morning for 14 products.

Frequently asked questions

Is it legal to find companies using a specific software this way?

Reading a public web page and recording what it loads is the same thing every search engine does, and certificate logs are published deliberately so that anyone can monitor them. The legal question is not about discovery, it is about what you do next. Contacting the businesses you found is governed by electronic marketing rules that vary by the recipient's jurisdiction, and those rules apply exactly the same way whether you built the list or bought it. Get advice on your outreach, not on your research.

Why not just buy technographic data from a vendor?

Buy it if the vendor already tracks your exact target and the price is under what your time is worth. The three reasons I built it myself: vendors only track technologies they chose to track, so mid-size platforms and tier-level distinctions are usually invisible; the data is sold to your competitors as readily as to you; and vendor detections are inferred from crawls or job postings on a refresh cycle you do not control, so you inherit their staleness without being able to measure it. Building it yourself costs a few sessions and gives you a number for freshness because you set the verification date.

How many businesses can you realistically find on one platform?

It depends entirely on the platform's size and how well it hides. My run produced 1,419 verified businesses from one platform, which was far from all of them. Treat the output as a large, provable sample of the market rather than a complete census. A verified sample of a thousand businesses that all demonstrably run your displacement target is worth considerably more than a complete list you cannot trust.

What does this cost to run?

Zero, on the tools I used, which was a deliberate constraint rather than an accident. Free tiers of source-code search, general web search, an open crawl archive, and public certificate logs cover every stage. The costs that do appear are your time and, if you automate the verification and enrichment passes, model tokens. The reason I keep the spend at zero is that it forces the method to stay reproducible for someone who has not raised money.

Does this work if my product does not replace a hosted platform?

Partially. The fingerprint stage needs something specific to detect, so if your buyers are not identifiable by a trace they leave in public, this method has nothing to grip. It works well for anything that displaces, extends, integrates with, or fixes a hosted product. It works poorly for horizontal products whose buyers look like everyone.

Come build the list with me on Tuesday

The full walkthrough is live on Tuesday, August 11 at 10:00 AM Eastern: Use Claude Code to Find Every Business Running the Software You Replace. You get the six stages end to end with the real numbers, including which index hit 99% precision and the two mistakes I have described here in the form of the actual code that caused them. Everyone who attends gets the Claude Code skill, and the recording is included.

If you would rather have it all at once, the Reinventing AI Accelerator includes this session and every past one, along with the apps, tools and agents each one shipped. It is $189 and you can cancel any time.

One small ask either way: if you build a fingerprint for a platform I have not looked at, tell me what coverage it measured. That number is the most useful thing in this entire method and almost nobody publishes it.