Use This Prompt to Analyse a Competitor's Tech Stack

A technology detection export is a list of what a browser downloaded on the pages that were scanned. Everything in it is true and the scope is narrower than almost anyone reads it as being.

Consider three situations that produce an identical line. A tracking tag fired once, on a single campaign landing page that 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 a customer depends on. Those are three different companies, and the export writes them the same way.

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

Four inputs, and they are listed here in a deliberate order: by what it would cost the competitor to be wrong about each one. A vendor list published alongside a data-processing agreement is a contractual undertaking. A status page has to be accurate or customers notice within the hour. An integrations directory is marketing and costs nothing to be optimistic in. A detection profile the competitor did not write and has never seen.

The order is not housekeeping. A model given the detection profile first will build its picture from the marketing layer and then fit everything else around it, because that is the material it met while it had no other frame. Given the contractual list first, the detection profile arrives as a set of details to place inside a structure 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 is the only one of the three that reports a change.

Read the discard list at the end of the first output before the groups above it. Asking the model to name what it threw out as ubiquitous is the cheapest audit available on this job: if a consent banner and a font service were discarded, the filter worked, and 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 opened the list that company publishes itself and compared.

Which layer goes missing

Hosting, content delivery and payments came back correctly. Those three have been true about that company for years, which is the whole explanation: an answer assembled from what has been written about a company is weighted towards the years when most of the writing happened. Six of the entries it missed exist to serve a single feature area, and they are the six that would have told you where this company is currently spending.

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

The last row is the one worth keeping. A source that states its own boundary lets you stop; an answer that does not state one leaves you unable to tell a gap in the evidence from a gap in the company.

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

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 undertake to give 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 were marked effective thirty days after the page itself was last modified.

An announced vendor is not an adopted one

Which is exactly why the prompt separates them into their own list rather than folding them in. An entry that takes effect next month is a decision already taken and a capability not yet shipped, and those two states support completely different actions. Treating them as one produces a competitor who already does something they have only agreed to start doing, which is the sort of claim that reaches a sales call and gets corrected by the buyer.

None of this survives contact with a profile that arrived without a date on it, which is the real reason the input contract insists on the export rather than the screenshot. It is also why engineering job postings are worth reading beside the list: a role naming a tool that does not appear anywhere in the published stack is either something built in house or something arriving, and the posting is usually months earlier than any other public trace.

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

The practical consequence is that 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 find out about a new model provider a year after it was published, with an effective date on it that you could have had in advance. What you want is not a schedule at all, but to be told when a 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, and the same discipline makes the next feature comparison easier to defend, because a capability and the vendor underneath it tend to appear in the public record at different moments.

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

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