Research and data

From one company name or website, scripts collect what the company has made public, all at the same time: a browser reads the site's pages and the code they load, a scraper pulls the social accounts and community channels, and other scripts read the team, the funding records, the partnership claims and the ad libraries, plus on-chain activity for a crypto company. Each script saves what it found with the link it came from before any analysis starts.

A model compares the sources and flags what does not add up, such as a partnership the partner never announced or a user count the blockchain does not show. I review the flags and pick the questions worth asking, so you walk into the meeting knowing which claims hold and which to push on.

A map of what a competitor's product does, taken from the product itself (its pages, the code it ships and the requests it makes while it runs), with proof behind each finding.

A browser opens the live product as a real user would and records its traffic: which servers it calls and what data it sends. Python reads the code the product ships for the public keys, server addresses and outside services named in it, and the security settings its servers send back; a mobile app is taken apart to list what is inside. Everything is read from the outside, in the same session an ordinary user has, and any key found is listed, never used.

A model sorts the evidence into the features that exist, the features that appear only on the marketing site, and the services the product depends on. You plan your roadmap and positioning against what the competitor has shipped, with a recorded request or a line of their code behind each point.

From your company and your category, scripts find the companies in your market: the ones in the search results and ad libraries your buyers see, in investor portfolios, directories and company registries, and on GitHub. The same company often shows up several ways, so an AI model decides which records are one company, code merges them and keeps every source attached, and a pair of records it is unsure of waits for a person.

Each company then gets the same set of readings: its site and the code behind it, its X account, its community, its team, its funding, its partnerships, its ads and growth channels, its GitHub and, for a crypto company, its on-chain activity. You see them side by side with your gaps marked, such as a channel where a competitor publishes and you have no presence, or a pricing or docs page your rivals publish and you do not. Any company on the map can then get a full company file.

A scraper pulls the recent posts and videos of each account you list (yours, your competitors' and the leaders in your category) with their views and engagement. Python scores each post against that account's own average.

For the posts that beat their account's average by the most, a model looks at frames from across the video and labels the opening shot, the text on screen, the format and the subject. You get a brief on what to make next, with the posts behind each point.

Ask questions of your own documents and data, and each point in the answer comes with the passage it came from, so you can check it at the source.

Python splits your documents (reports, whitepapers, contracts, support logs) into passages, and an embedding model turns each passage into a searchable form, a vector, stored in Postgres with pgvector or in ChromaDB with the document and the place it came from.

A set of questions, written as prompt templates, says what each document must answer. For each question the system finds the closest passages, and a model answers from them alone and cites each one; where they do not answer the question, it says so, and the question is marked unsupported. On a set of whitepapers, the same questions put each project through one standard, so the comparison is fair.

Each candidate or vendor is read against the criteria you set, and you get a shortlist with the evidence behind each decision, while the final call stays yours.

You write your criteria, one per line. As applications and proposals arrive (PDFs, profiles, email threads), code removes each person's name, email and phone, then a model, or a backup if it fails, reads each one against each criterion and records a pass or a hold with the passage that decided it. Code checks that each quoted passage is in the document before the decision counts.

You read a shortlist of those that pass every criterion, with the reasons attached. Each application that was held keeps the criterion that stopped it, so you can reopen it if your criteria change. Who to hire or buy from is still your decision, and your team no longer spends hours on the first read.

The models run only on zero-data-retention endpoints, so no model provider keeps what it reads, and the record of each decision sits in your own Postgres, deleted after the period you set.