Три ссылки, три разные ниши, один и тот же пайплайн:
Каждая страница собрана так: я наговариваю минуту голосом, что мне нужно. Дальше агент сам расходится по источникам, сводит найденное, верстает статическую страницу, коммитит в приватный репозиторий и деплоит на Vercel. Возвращается уже со ссылкой.
Решает то, что подключено к агенту
У меня Claude Code, OpenClaw и Hermes. Оболочки разные, ресёрч они делают одинаково хорошо. В комьюнити это формулируют жёстче: средняя модель с хорошей обвязкой побьёт топовую с плохой. LLM это просто мозги, а мозгам нужны руки.
Поэтому и выбирать оболочку надолго не надо. Я гоняю все три, и пайплайн в них плюс-минус одинаковый. Меняется способ подключить инструменты, а порядок работы остаётся тем же: разошёлся по источникам, свёл, собрал страницу, выложил.
Мой набор под ресёрч:
- Веб-поиск (Exa) закрывает внешний рынок: кто что запустил, кто умер, что пишут в документации вендоров.
- Perplexity идёт за цифрами и статистикой, когда данных мало.
- Свои векторные базы дают то, чего нет в вебе: мнения, боли и реальные кейсы практиков, которые нигде не оформлены статьёй.
- askaizer и ProdSignal, мои отдельные проекты. Второй это каталог запусков с Product Hunt и других платформ: 8 000+ продуктов стартапов больше чем за год, по ним видно, где спрос есть, а продуктов почти нет.
- GitHub API приносит открытый код, который можно взять вместо написания с нуля.
- GitHub плюс Vercel это хвост пайплайна: пуш, автодеплой, публичная ссылка.
Ни один пункт не обязателен. Без своих баз получится тоньше, но получится: веб-поиска и GitHub хватает, чтобы собрать приличную карту рынка.
Два режима, и второй сильно интереснее
Первые два лендинга сделаны с чистого листа. Вопрос звучал как «что вообще в мире делается в этой нише». На выходе витрина. По маркетингу это 130 продуктов, 10 направлений и 29 категорий фич. По психологии 14 продуктов, 32 use-case паттерна и три слоя рынка. Полезно, когда только присматриваешься.
Третий лендинг делался иначе. У человека была не идея, а готовый план реализации с чёткими требованиями: агрегатор данных о здоровье на Java и Spring Boot, сбор из нескольких источников, аналитика поверх, описанные сущности и переходы состояний. Он понимал, чего хочет, и был готов садиться за код. Я отдал агенту этот план как вводные и попросил бить по замыслу, а не по рынку вообще.
Жанр поменялся полностью. Вместо витрины получился разбор того, что в плане не работает:
- Базовый пункт «интеграция с Google» в задуманном виде не существует. Google Fit REST API помечен deprecated 1 мая 2024, и в тот же день закрыта регистрация новых разработчиков. Google прямым текстом написал: «There is no alternative to the Fit REST API».
- Из веб-бэкенда до Health Connect не достучаться: нет OAuth со стороны сервера, нет токена, нет вебхука. Им Google заменил Fit на Android, и живёт он только на устройстве.
- Strava подключать нельзя вообще. Их API Policy, действующая с 1 июня 2026, запрещает использование данных в AI, включая дословно «ingestion into a context window or working memory». То есть нельзя не только обучать на них модель, но даже просто подгружать их ей в контекст. Отдельно запрещено хранение в векторных базах и любых постоянных индексах.
- Все health-скоупы Google относятся к категории Restricted. Без внешнего аудита безопасности приложение упирается в потолок тестовых пользователей, и снять его можно только платной ежегодной процедурой.
Плюс архитектурная находка. Google Research сравнил два подхода к AI поверх данных о здоровье на одном и том же наборе. Агент, который генерирует и исполняет код по таблицам, отвечает верно на 84% объективных числовых запросов. Дообученная под коучинг модель, рассуждающая текстом, на 0%. Не «хуже», а ровно ноль. Для архитектуры вывод прямой: LLM в таком продукте должна писать запросы к базе, а не пытаться анализировать данные в контексте.
Карта с чистого листа отвечает на вопрос «что тут есть». Анализ под план отвечает на вопрос «что из задуманного развалится и когда». Второе дороже стоит, потому что его нельзя нагуглить: нужно сопоставить конкретный замысел с реальным статусом двух десятков API и юридическим слоем.
И нужен такой прогон ровно в этой точке: когда план уже есть, а код ещё не написан. Здесь неверное допущение стоит вечера. Переписать план, выбрать другой источник данных, поменять архитектуру: всё это ещё правки в документе. Если же пойти по первоначальному плану и упереться в то же самое через месяц, оно стоит этого месяца, и переписывать придётся уже не план, а написанное.
Агент врёт, и это не лечится промтом
Пайплайн ошибается. Проверка фактов из него не выпадает.
Сегодня, уже после того как лендинг был опубликован и отправлен человеку, я прогнал ключевые утверждения через отдельный фактчек. И снял одно своё же. Страница утверждала, что Google Health API отдаёт только данные Fitbit и Pixel Watch. И выводила из этого: универсальный агрегатор реализуем исключительно как Android-приложение.
Официальная документация говорит иначе. На лендинге API написано про данные «from Fitbit, Pixel Watch, and other third-party devices and apps». А в описании есть Reconciled Stream: он сводит пересекающиеся точки из нескольких источников. Своим сбором закрыты Fitbit и Pixel, но чужие устройства в API попадают, если пользователь подключил их сам. Формулировка на странице занижала возможности, и человек мог отказаться от рабочего пути.
Правку я внёс, страницу передеплоил. Google тут ни при чём: цифры и статусы, которые агент принёс, надо прогонять отдельным проходом с требованием первоисточника. Без выделенного этапа сбора фактов агент дозаполняет пробелы вместо того, чтобы отдать их как ошибку. На объёме такое глазами не ловится.
Что понял
Карта рынка по нише это теперь полчаса работы агента и задеплоенная страница на выходе. Выбирать нишу от этого проще не стало: ошибка тут всегда стоила дорого и стоит дорого сейчас. Изменилось другое. Проверить себя перед стартом стало дёшево. Раньше такой разбор занимал несколько недель, поэтому его чаще всего просто не делали.
Автоматизировалась сборка. Достоверность не автоматизировалась. Пайплайн отлично приносит материал и отвратительно отвечает за него. Поэтому фактчек я держу отдельным этапом наравне с поиском, а не финальной вычиткой.
Тот же материал в виде обычного текстового документа человек пролистает. Статическая страница с фильтрами по рискам, статусам API и категориям открывается с телефона и читается как продукт. Стоит она столько же.
Источники
- Google Fit Migration FAQ - первоисточник цитаты про отсутствие альтернативы и закрытие регистрации с 01.05.2024
- Health Connect API reference - подтверждение, что это offline on-device хранилище
- About the Google Health API - Reconciled Stream, отключение Fitbit Web API в сентябре 2026, Restricted-скоупы
- Google Health API - формулировка про «other third-party devices and apps»
- Strava API Policy (2026) - секции 5.3 и 5.5: запрет AI-обработки и постоянных индексов
- Transforming wearable data into personal health insights - 84% против 0 на объективных запросах, Nature Communications
- App Store Review Guidelines - раздел 5.1.3 про данные о здоровье
- You can now deploy Lovable apps to Vercel - zero-config деплой сгенерированного сайта
- Introducing Deep Research and Deep Research Max - ресёрч-агент, который ходит и в веб, и в приватные источники одним вызовом