Discovery & Research
LiveSaaS discovery is now AI-native.
The problem
Every software directory is written once, by whoever wanted the traffic, and is wrong within a month. Listings describe what was announced rather than what shipped; the ordering is a popularity contest among people who came to be ordered; and there is no way to tell a live product from an abandoned one without visiting it yourself. The catalogue's freshness is the whole value, and it is the first thing every directory gives up.
Crawl, screenshot, and write
Scheduled in the database
REST, GraphQL, and MCP
How it works
Directory listings go stale the day they are published, because they are written once by whoever wanted the traffic. Superfluidity inverts that: an agent crawls the product, captures what it actually sees, and returns a listing in about thirty seconds, then re-crawls weekly so changes surface on their own. Claims are marked verified, failed, or unverifiable against that evidence, and ranking comes from measured activity rather than upvotes — which is the part a directory cannot fake. Browsing is free; the catalogue is readable by machines as well as people, over a REST API and an MCP server.
An agent opens the product in a real browser, screenshots it, and reads what is actually on the page. The listing comes back in about thirty seconds.
Each claim is marked verified, failed, or unverifiable against what the crawl actually saw. Unverifiable is a real answer rather than a placeholder — it means the evidence did not settle the question, which is different from the claim being false.
Every listing is re-crawled weekly, so it tracks the product rather than the launch. The schedule lives in the database rather than in a worker, so it fires whether or not a worker happens to be running and a deploy cannot silently drop a cadence.
Natural-language search runs full-text and vector retrieval together and fuses the results, because the two fail in opposite directions. The same catalogue is readable over a REST API with a self-describing schema, over GraphQL, and over an MCP server.
What it does
Engineering
The part of a build that is worth reading is rarely the feature list. These are the calls that shaped the product, and the reasons they were made.
There is deliberately no featured or trending sort. Every sort is a measurement or plain alphabetical, because a sort we choose is a ranking presented as a fact. The default orders by when a product last materially changed rather than when it was last crawled — the latter would be a sort over our own scheduler, dressed up as a sort over the catalogue.
There is nothing to re-read: we were told, we did not look. Crawling one would be measuring an assertion, so those listings are excluded from the refresh schedule at the source rather than filtered out later.
The MCP tool descriptions are static literals with nothing interpolated from the database, because a description that changes with our data is a data channel into a stranger's model context. Instructions about how to treat our data are defensive; instructions about what to conclude are not.
The credit ledger is append-only and the database enforces it — update and delete are revoked outright, so a correction is a new row and no code path can rewrite history. The balance is summed on every read rather than cached, which makes it impossible for a cached total to drift from the entries behind it.
Limits
Every product page lists what the software can do. This one lists what it cannot, because that is the half you would otherwise find out afterwards.
Questions
Also from the studio
Next step
Tell us what the software has to do and who it is for. We come back with a scope, a first milestone, and a number. Discovery is free and commits you to nothing.