Prompts to Analyse a Competitor's Tech Stack

A technology detection export lists what a browser downloaded on the pages that were scanned. Every line in it is true. The scope is far narrower than most people read it as.

Three very different situations produce the same line. A tracking tag fired once, on one campaign page a contractor built two years ago. The same tag runs on every page of the marketing site. Or the library sits inside the logged-in product, handling something customers depend on. Those are three different companies, and the export writes all three the same way.

So the first job of the prompt is not to classify anything. Make the model say where it saw each entry, and what real use of it would look like. That comes before any sentence starting “this suggests they”. An unmarked list invites a story, and a model asked for a reading will supply one whether the evidence carries it or not.

Four inputs, and the order matters. They are ranked by what it would cost the competitor to be wrong about each one. A vendor list published beside a data-processing agreement is a promise they signed. A status page has to be right or customers notice within the hour. An integrations directory is marketing, and it costs nothing to oversell. A detection profile is the only one the competitor never wrote and has never seen.

The order is not tidiness. Give a model the detection profile first and it builds its picture from the marketing layer. Everything else then gets fitted around that, because it is what the model met while it had no other frame. Give it the signed list first and the detection profile arrives as detail to place inside a shape that already exists.

Three passes, doing genuinely different work. The first turns a profile into a reading. The second reads the integrations directory, which is the one input that describes the buyer rather than the builder. The third needs two captures, and it is the only one that reports a change.

Read the discard list at the end of the first output before you read the groups above it. Asking the model to name what it threw out as too common is the cheapest audit on this job. If a consent banner and a font service were discarded, the filter worked. If a data warehouse was discarded as ordinary, the reading in front of you is about websites in general rather than about this company.

We asked which third-party vendors a real product runs on. Then we opened the list that company publishes itself and compared the two.

Which layer goes missing

Hosting, content delivery and payments came back correctly. All three have been true about that company for years, and that is the whole explanation. An answer built out of what has been written about a company leans towards the years when most of the writing happened. Six of the missed entries serve a single feature area, and those six are the ones that would have shown you where this company is spending now.

The second half of the ungrounded answer is a different problem in the same clothes. Languages, databases and front-end frameworks are not on a sub-processor page at all. That document lists companies handling personal data, not the technology a product is built in. Two kinds of claim arrived under one heading: one checkable against a published source, one not. Nothing in the output separated them.

The last row is the one worth keeping. A source that states its own boundary lets you stop. An answer with no stated boundary leaves you unable to tell a gap in the evidence from a gap in the company. The same boundary problem decides whether a competitor website teardown is describing a site or describing the pages you happened to save.

A stack read once is a photograph. It tells you where a competitor stood on the morning somebody ran a scan. Every sentence it produces is written in the present tense anyway.

Two things fix that, and neither is a better prompt. The first is capturing the same list twice and diffing it, which is the third prompt above. The second is reading the column almost nobody asks for. A published vendor list carries effective dates, and some of those dates have not arrived yet. Vendors promise their customers notice before they add a processor, so the list names the companies they are about to start using. On the page we checked, three entries took effect thirty days after the page itself was last changed.

An announced vendor is not an adopted one

That is why the prompt puts them in their own list instead of folding them in. An entry that takes effect next month is a decision already taken and a thing they have not shipped yet. Those two facts point to completely different actions. Treat them as one and you get a competitor who already does something they have only agreed to start doing. That claim reaches a sales call and gets corrected by the buyer.

None of this survives a profile that arrived without a date on it. That is the real reason the input contract asks for the export rather than a screenshot. It is also why engineering job postings are worth reading beside the list. A role naming a tool that appears nowhere in the published stack is either something built in house or something arriving, and the posting usually lands months before any other public trace. Which makes a competitor's open roles the earliest readable surface for a stack change, and the only one with a date on it.

Every layer of a stack moves at its own speed, and the layer that changes most often means the least. Tags, widgets and marketing tools turn over constantly. Hosting, data warehouses and model providers barely move. A move there is a decision somebody had to argue for inside the company, which is why it is worth an alert and the tag changes are not.

So this analysis has no natural re-run date. Run it monthly and you spend the time re-reading a marketing layer. Run it annually and you hear about a new model provider a year late, with an effective date you could have had in advance. What you want is not a schedule. You want to be told when one specific document changes.

The output belongs somewhere it can be compared against itself later. A dated technology section inside a competitor profile is enough, as long as every line keeps the source it came from. The same habit makes the next feature comparison easier to defend, because a capability and the vendor underneath it tend to surface in the public record at different moments.

One limit does not move. A change in a vendor list tells you that something changed, never why. The why is what decides whether it matters to you. A data warehouse swapped to cut costs and one swapped because a new product needs it look identical from outside, and no amount of watching tells them apart.

Flares monitors competitor documentation, trust pages and changelogs. A vendor appearing or a page being re-published arrives dated, rather than being discovered at the next review. What the change means for your roadmap stays a judgement somebody on your side has to make.