A term you keep seeing is not a signal: the data model I use to check the evidence

Every week or so a word shows up that I do not recognise. A product name in a Show HN post. A phrase in a repository README. Something a client says on a call as if everyone already knows it.

The usual response is to open the link, decide it looks interesting, save it somewhere, and close the tab. Two weeks later the word comes up again, and all that survives is the vague feeling of having seen it. What caught my attention, and which questions were still open at the time, are gone.

That is not a curiosity problem. It is a record problem. The useful part of a new term is almost never the definition. It is the provenance: where it came from, when it first appeared, how many independent people are actually discussing it, and what you would try first if you did anything at all.

Like.Do is what I built around that idea: a discovery site for emerging terms where each term is stored as an object with its evidence attached, instead of as a card in a feed.

What a term record actually needs

Reading three summaries about a term produces the feeling of understanding it. A more reliable way to break that feeling is to split what you have into two columns.

Known: who made it, when it shipped, what problem it addresses, whether there is a usable public implementation.

Unknown: whether anyone actually has this problem, what the current alternatives are, what the cost structure looks like, whether anyone would pay.

The second column is almost always longer, and that is the point. The size of the unknown column is roughly the amount of room a term still leaves you.

So the minimum record I want per term is: a short explanation, the original source pages with author and publication date, the date the term was first observed, a mention count over a rolling window, and the related sites split by kind — official, tool, reference, code repository. Where an assessment has been published, it answers three separate questions: what could be built, what the first step to test looks like, and what to watch out for. Those three are deliberately separate, because "could be built" and "worth building" are different claims.

You can see the shape of one record on a term brief.

Reading it as data instead of as a feed

The reason this became a data problem rather than a note-taking habit is that I wanted to query it. The site exposes a read-only REST API and an MCP endpoint for the entries whose sources allow export.

curl -s "https://like.do/api/v1/discoveries?q=agent&sort=signal&limit=5" \
  -H "Authorization: Bearer $LIKEDO_KEY"

The list endpoint returns the term, its tags, first and latest observation dates, evidence count and channel count, plus pagination. The detail endpoint returns one entry with up to 100 evidence records, each carrying the source name, authors, licence and terms URL, so attribution travels with the data instead of being reconstructed later.

Query parameters are intentionally boring: q is a substring match capped at 120 characters, sort takes recent or signal, source filters by source ID, and limit/offset page through results. Keys are read-only and limited to 60 authenticated requests per minute, shared between the REST and MCP endpoints, which is enough for a nightly job and not enough to treat the API as a data warehouse.

For MCP clients the same data is exposed as two tools, list_discoveries and get_discovery, over Streamable HTTP at https://like.do/api/mcp. The client needs to support a custom Authorization header; a cookie session or an MCP OAuth flow will not authenticate. Details are in the API documentation.

Four things the model refuses to do

Most of the design work went into what the data refuses to claim, because a discovery dataset fails quietly if it does not.

• First observed here is not first in the world. The observation date means "first seen inside the collection window", not "globally first". Those two get blurred constantly in anything called a trending list, and the difference is exactly what decides whether you are early or late.
• Missing data stays missing. When search volume is not available, the entry says so. No estimate is substituted to fill the space, and the semantics field in API responses carries that disclaimer so it can be shown to whoever consumes the data.
• Attention is not demand. GitHub stars, HN points and comment counts measure attention. A term can be recorded, discussed and assessed without anyone wanting to pay for a solution.
• The API is not the homepage. Only entries that passed review and whose sources permit export are returned, so the API is a subset. The IDs are 64-character hex strings taken from the list response; the slug in a web URL is not an ID.

Two operational notes that will save you an afternoon: pagination is not a snapshot, so entries can appear or be withdrawn between pages and merged results should be deduplicated by ID; and 429 should be retried with bounded backoff rather than assumed to include a Retry-After header.

What I actually use it for

Three things, none of them "find the next wave":

1. Turning the terms I scroll past each day into a list I can go back and check, with links that still work.
2. Deciding whether a phrase I am about to write a whole article around has anything behind it, or is just a phrase.
3. Watching a handful of keywords and sites over time, privately by default, to see whether a direction keeps producing evidence or quietly stops.

The documentation explains where candidates come from, and there is a page on sources and corrections for the cases where an entry is wrong.

The honest framing is this: emerging-term discovery watches other people's public moves, not the market itself. A tool can make the evidence legible and keep it from evaporating before you use it, but it cannot tell you whether anyone will pay. That part still costs an afternoon and three real users.