A public research notebook from one developer

Not reviews, not a leaderboard, and not an exposé. These are the notes I keep while studying other people's products: how I look at them, what I found, and what I took away.

Why this exists

I build apps at Gaiya Lab, on my own. Anyone shipping products ends up needing the same handful of answers: is somebody already doing this, how do they get customers, are they making money, and is it worth entering.

Most published "product analysis" is the company's own account of itself, restated. I would rather know what the response headers say, how many URLs are in the sitemap, what the public API documentation gives away, and whether the same number was there in a snapshot six months ago.

Method

• Measure first, read second. Response headers, sitemaps, JS bundles, public API docs. Marketing copy is one input to verify, not a source.
• Go back in time. Wayback snapshots compared version against version. A number that has not moved in three months says more than the number itself.
• Leave a probe behind. Every teardown ships with a script that re-checks weekly. Time answers questions a website never will.

Limits

Everything here follows the same rules:

• Read-only collection, and only documents the product published itself
• No write operations, no management endpoints, no attempt to exceed granted access
• Nothing published that could function as an attack recipe
• State the observation and leave the judgement to the reader. "This figure is identical across three snapshots" is both more accurate and more damaging than "they are making it up"

If a product written about here believes something is wrong, or wants a passage taken down, write to Gaiya Lab and I will check it and correct it.

Following along

There is no mailing list and there is not going to be one for a while. There isRSS, and llms.txt for machines.