Where to find out what tools a company runs
If you sell a tool for engineers, one fact changes your first message more than any other: what the company already uses. Someone who runs your main competitor needs a different pitch from someone who runs nothing. Someone who runs a tool that works with yours needs a third.
No company publishes a full list of its tools. You build the picture from clues. This article shows where those clues are, how much each one proves, and how to write down what you find without overstating it.
Read the clue, then rate it
Every clue has a strength. Before you list a tool, ask what the clue proves:
- Strong: The company says it uses the tool, in its own words, or the tool is visible in code that it serves.
- Medium: A job post asks for experience with the tool. It tells you that some team uses it, and not which.
- Weak: One person's profile or a single comment mentions it. Treat as a lead to check.
Write the strength next to each tool in your notes. A list of tools with no strength is a list of rumors.
Where to look
1. Job posts
The most useful source for most sellers. A posting for a reliability engineer often lists the monitoring tools, the cloud provider, the languages and the deployment tools. Read the "requirements" and "nice to have" parts and write down the exact names. Note the date: a post from last month reflects the current stack; one from three years ago reflects history.
Two cautions. First, a "nice to have" can mean a tool the team is moving toward, not one it runs. Second, a post covers one team. A different team at a large company may run something else.
2. The company's own website
The pages a company serves can reveal tools in use. A site often loads scripts and styles from analytics, chat, monitoring and payments services, and those references are visible in the page's code. This shows what the marketing site uses, which can differ from what engineering uses. It is a clue about web and customer-facing tools, and a weak one about the internal stack.
Look also at the status page. It often names the provider it runs on, and its incident history tells you which parts of the system hurt.
3. Engineering blog posts and talks
When engineers write about how they built something, they name tools. "How we moved our pipeline to a new queue" tells you more than any listing. Search the company's engineering blog and the video archive of conferences where its engineers have spoken. Note who wrote it and when. A tool named in a five-year-old post may be gone.
4. Public repositories
If the company publishes code, its repositories show real use: dependency files, configuration for build and deployment tools, and workflow files. A dependency list names libraries and services the code talks to. The commit dates show whether the code is active. Public repositories rarely cover the main product, but they often cover the platform and tooling teams, who are often your buyers.
5. Documentation and integration pages
Companies that offer a product to developers often publish a list of what they integrate with, or a guide on how customers can run their product with certain tools. Vendors also publish customer stories that name a customer and the tools it uses. Check the date and read whether the customer story is about the whole company or a single team.
6. Filings and news
Public companies sometimes name major vendors or platform moves in filings and earnings talk. This is rare and high-level, but when it exists it is strong: it is the company speaking, with a date.
7. People's public work
Conference slides, public talks and posts by an engineer can show what their team uses. Keep it to work. The goal is the stack, not the person.
Put the clues together
| Tool | Clue | Date | Strength |
|---|---|---|---|
| Kubernetes | Engineering article on moving to it | Sept 12 | Strong |
| A monitoring tool | Required in a reliability job post | Oct 6 | Medium |
| A second monitoring tool | Mentioned by one engineer in a talk | Aug 3 | Weak |
This table is invented for illustration. The point is the shape: a tool, where you saw it, when, and how much it proves.
What the tools tell you
- They run a competitor. Find out how long, how happy and what the contract looks like. Don't open by attacking the tool.
- They run a neighbor. A tool that works beside yours can be your way in. Ask how the two connect today.
- They run nothing in your category. Then the question is whether they feel the problem at all. Look for the pain, not the tool.
- They are moving. A migration post or a new role for a platform shift is a reason to call now. The article on buying signals shows how to judge its age.
What not to do
- Don't say "I see you use X" unless the clue is strong. If a job post is your only clue, say "I saw a posting that mentions X."
- Don't treat a missing clue as a negative. Not finding a tool doesn't mean it isn't there.
- Don't assume one team speaks for all. At a large company, find the unit first. The article on finding the right person at a large company shows how.
Where Repclose fits
Repclose reads the same public places for you: the company's own pages, job posts, GitHub activity, filings and news. It uses what it finds to judge fit against your sales profile and to say why now, and each point links to its source with the publication date where one is available. A point that is an inference is labeled as one.
It doesn't see inside a company, and it can miss tools that leave no public trace. Use the plan as a start and confirm the important ones on the call. Look at the sample brief to see how sources are shown, or try your own accounts.