Three links, three different niches, the same pipeline behind all of them:
Every one of those pages was built the same way. I spend a minute dictating what I need. The agent then goes out to the sources on its own, pulls everything together, builds a static page, commits it to a private repo and deploys to Vercel. It comes back with a link.
What matters is what the agent is plugged into
I run Claude Code, OpenClaw and Hermes. Different harnesses, and all three do research equally well. The community puts it more bluntly: a mid-tier model with a good harness beats a top model with a bad one. An LLM is just a brain, and a brain needs hands.
Which is also why you shouldn’t commit to one harness for long. I run all three, and the pipeline is roughly identical in each. What changes is how you wire the tools in. The order of work stays the same: fan out across sources, pull it together, build the page, ship it.
My research stack:
- Web search (Exa) covers what’s happening out in the market: who launched what, who died, what vendor docs actually say.
- Perplexity goes after numbers and statistics when data is thin.
- My own vector databases hold what the web doesn’t: opinions, pain points and real cases from practitioners that nobody ever wrote up anywhere.
- askaizer and ProdSignal, two separate projects of mine. The second is a catalog of launches from Product Hunt and other platforms: 8,000+ startup products over more than a year. It shows where there’s demand but almost no products.
- GitHub API brings in open source you can take instead of writing from scratch.
- GitHub plus Vercel is the tail end of the pipeline: push, auto-deploy, public link.
None of this is mandatory. Without your own databases the result comes out thinner, but it still works: web search and GitHub are enough to put together a decent market map.
Two modes, and the second one is far more interesting
The first two landing pages started from a blank slate. The question was “what is the world actually doing in this niche?” What you get is a catalog. Marketing came out as 130 products, 10 segments and 29 feature categories. Psychology as 14 products, 32 use-case patterns and three market layers. Useful when you’re still looking around.
The third one was built differently. The person didn’t have an idea, they had a finished implementation plan with clear requirements: a health data aggregator built in Java and Spring Boot, ingestion from several sources, analytics on top, entities and state transitions all spelled out. They knew what they wanted and were ready to start writing code. I handed the agent that plan as input and told it to go after that specific plan, not the market in general.
The genre changed completely. Instead of a catalog I got a breakdown of what doesn’t work in the plan:
- The foundational piece, “integration with Google,” does not exist in the form it was planned. Google Fit REST API was marked deprecated on May 1, 2024, and registration for new developers closed the same day. Google put it plainly: “There is no alternative to the Fit REST API.”
- You can’t reach Health Connect from a web backend at all: no server-side OAuth, no token, no webhook. It’s what Google replaced Fit with on Android, and it lives only on the device.
- Strava can’t be connected, period. Their API Policy, effective June 1, 2026, bans using the data in AI - their exact words: “ingestion into a context window or working memory.” So you can’t train a model on it, and you can’t even load it into the model’s context. There’s a separate ban on storing it in vector databases or any persistent index.
- All Google health scopes fall under the Restricted category. Without an external security audit the app is capped at test users, and lifting that cap means a paid annual review.
Then there’s the architectural finding. Google Research compared two approaches to AI on top of health data using the same dataset. An agent that generates and runs code against the tables answers 84% of objective numerical queries correctly. A model fine-tuned for coaching that reasons in text: 0%. Not “worse” - exactly zero. The takeaway for architecture is blunt: in a product like this the LLM should be writing queries against the database, not trying to analyze data inside its context.
A blank-slate map answers “what’s out there?” An analysis against a plan answers “what part of this falls apart, and when?” The second one is worth more, because you can’t google it: you have to check a specific plan against the real status of two dozen APIs and the legal layer on top.
And you need that pass at exactly this point: the plan exists, the code doesn’t yet. Here a wrong assumption costs you an evening. Rewrite the plan, pick a different data source, change the architecture - all of that is still just editing a document. Go down the original path instead, hit the same wall a month later, and it costs you the month - and now what you’re rewriting isn’t the plan, it’s the thing you built.
The agent lies, and no prompt fixes that
The pipeline gets things wrong. Fact-checking is not a step you get to skip.
Today, after the landing page was already published and sent to the person, I ran the key claims through a separate fact-check. And I killed one of my own claims. The page claimed the Google Health API only returns data from Fitbit and Pixel Watch. From that it concluded a universal aggregator could only be built as an Android app.
The official docs say otherwise. The API landing page describes data “from Fitbit, Pixel Watch, and other third-party devices and apps,” and the overview documents a Reconciled Stream that merges overlapping points from several sources. Google’s own data collection covers Fitbit and Pixel, but third-party devices do reach the API if the user has connected them. My wording understated what’s possible, and it could have talked someone out of a viable path.
I fixed it and redeployed the page. Google isn’t the problem here: the numbers and statuses an agent brings back need a separate pass that demands a primary source. Without a dedicated fact-gathering step the agent fills the gaps in instead of handing them back as errors. At volume you won’t catch that by eye.
What I took away
A market map for a niche is now half an hour of agent work and a deployed page at the end. None of this made picking a niche any easier: getting that wrong was always expensive and still is. What changed is something else. Checking yourself before you start got cheap. That kind of breakdown used to take weeks, which is why most people just skipped it.
Assembling it got automated. Verifying it didn’t. The pipeline is excellent at bringing material in and terrible at standing behind it, so I keep fact-checking as its own stage alongside search, not as a final proofread.
Hand someone the same material as a plain text document and they’ll skim it. A static page with filters by risk, API status and category opens on a phone and reads like a product. It costs the same to produce.
Sources
- Google Fit Migration FAQ - primary source for the “no alternative” quote and the May 1, 2024 registration cutoff
- Health Connect API reference - confirmation that it’s offline, on-device storage
- About the Google Health API - Reconciled Stream, Fitbit Web API shutdown in September 2026, Restricted scopes
- Google Health API - the “other third-party devices and apps” wording
- Strava API Policy (2026) - sections 5.3 and 5.5: the AI processing and persistent index bans
- Transforming wearable data into personal health insights - 84% versus 0 on objective queries, Nature Communications
- App Store Review Guidelines - section 5.1.3 on health data
- You can now deploy Lovable apps to Vercel - zero-config deploy for a generated site
- Introducing Deep Research and Deep Research Max - a research agent that hits both the open web and private sources in one call