Парсер инстаграм аккаунтов конкурентов и новый content-farm

752 мегабайта в холодном хранилище - столько весит zip с shutdown-бэкапом моего проекта Feberra от апреля 2026. Сервис я тогда закрыл, домены отпустил, S3 вычистил, но код, схемы базы и слепок Convex-функций оставил себе «на случай рестарта». В этом месяце я наконец распаковал архив: мне нужен внутренний content-farm для команды, и в первую очередь - свой парсер инстаграм для рилсов конкурентов. Подозревал, что половину работы уже сделал в прошлой жизни.

И это был тот редкий случай, когда возврат к старому коду оказался не археологией ради ностальгии, а реальной экономией недель работы. Расскажу, что я внутри нашёл, что выкинул, что переосмыслил — и как из закрытого SaaS на Convex/Trigger.dev получился минималистичный internal-tool на нашем стандартном стеке Next.js + Supabase + Dokploy.

Что было: Feberra как SaaS-комбайн

Feberra задумывалась как полный цикл: «анализ рилсов конкурентов → генерация своего видео → публикация». Когда я распаковал 732 МБ архивных данных, на меня выпало 1176 Convex-функций и 90+ таблиц в БД. Это не маленький side-проект — это целый комбайн.

Я начал с того, что выгрузил по 5000 документов из каждой таблицы, сгруппировал по схемам, прогнал через скрипт распределения значений (status, signalType, eventType) и собрал документ на 631 строку — docs/feberra-scraper-pipeline.md. В нём — 17 ключевых таблиц scraper-пайплайна, две Mermaid-диаграммы (топология и sequence потока данных), карта задач Trigger.dev с реальными цифрами запусков и cron-расписанием.

Цифры заставили задуматься. Только за время жизни проекта:

• 323 000 dispatch-задач разосланы в очередь;
• 244 000 process-results вернулись из воркеров;
• основной cron шёл по расписанию 0 */2 * * * — каждые два часа скрапер обновлял метрики рилсов конкурентов;
• таблица trendSignalEvents весила 969 МБ — это была история того, как метрики каждого рилса менялись день за днём.

Изначально я подумал «оптимизировать, TTL, агрегации». Но потом дошло: это не балласт, это и есть основной продуктовый актив. Сигнал в Feberra — не свежий рилс конкурента, а рилс, который прошёл проверку временем. Лайфсайкл выглядел так:

свежий рилс (socialAccountReels)
  ↓ каждые 2 часа: скрапер обновляет метрики
  ↓ trends.analyze-workspace: смотрит динамику
  ↓ метрики растут → стадия SEED → SSN → SSN1 → SSN2
  ↓ при выполнении условий — попадает в trendSignals

Именно поэтому база сигналов была такой большой: каждый кандидат должен был пройти серию проверок «не просто всплеск, а стабильный рост». 969 МБ — это исторические снапшоты ради того, чтобы потом ответить «это уже плато, это всё ещё растёт, или это разово выстрелило и затухло».

Что выкинуть из старого

Когда я понял всю архитектуру старого проекта, нужно было решить: что переносить, а что нет. Контекст изменился радикально — раньше это был SaaS для широкой аудитории, теперь мне нужен internal-tool для команды из двух человек.

Поэтому я отбросил:

• Multi-tenancy, биллинг, кредиты, реферальную программу;
• Onboarding-funnel, email-маркетинг, лендинги тарифов;
• Интеграции с robokassa и lavaTop;
• Лицензии на коммерческие компоненты вроде designcombo (видеоредактор с таймлайном стоит $1.5-3k за коммерческую лицензию);
• AI-suggest для «выборки 100 юзеров» — я свою команду знаю поимённо;
• Robust error-handling под публичный API.

Это примерно 60% оригинального кода. Параллельно был ещё интересный момент: в старом проекте n8n использовался как резервный путь для скрапинга через сторонний API. Мы решили исключить и это — внешние SaaS-зависимости для парсинга социалок имеют свойство ломаться в самый неподходящий момент, а у нас уже есть собственный стек с GeeLark.

Новая архитектура: content-farm как internal-tool

Я сел переосмыслять продукт через сессию brainstorming — это формат, где AI задаёт вопросы по одному, без структуры, пока картина не сложится. Если коротко, конечная архитектура получилась такой:

1. Onboarding (один раз) — пользователь добавляет конкурентов из Instagram и TikTok в рамках проекта.
2. Trend Watching tab — плитки сигналов с метриками; есть фильтры (по стадии SEED/SSN, по нише, по дате), сортировка и блок «AI рекомендует сегодня» сверху.
3. Workspace tab — chat-driven рабочая зона; AI ведёт пользователя через шаги «анализ референса → адаптированный сценарий».
4. Проект как контейнер — каждый проект имеет свой список конкурентов, сигналов и чатов; переключалка в шапке.

Заметьте, чего здесь нет: AI-видео-генерации, озвучки, монтажа, публикации. Это было соблазнительно — но мы откладываем. Сейчас пользователь получает на выходе разбор сигнала и готовый адаптированный сценарий — и идёт снимать сам. Принцип «делай скучную часть продукта первой, не убегай в будущее».

Trend Watching: плитка сигнала

Плитка — главный объект на странице. После долгих обсуждений собрал её так:

• Вертикальный thumbnail рилса 9:16;
• Заголовок-хук («Жилая недвижимость — это пассив»);
• Метрики: просмотры, ER, длительность;
• Бейдж стадии в углу — SEED серый, SSN жёлтый, SSN1 оранжевый, SSN2 красный («горячо»);
• Спарклайн динамики просмотров — мини-график на 7-10 точек без осей. Сразу видно «это плато / это растёт / это падает»;
• Имя конкурента и ссылка на оригинал.

Эти два визуальных элемента — бейдж стадии и спарклайн — оказались критичными. SMM-щик не хочет читать цифры. Он хочет глазом пробежать по 30 плиткам и понять «вот эти три выстреливают прямо сейчас».

Workspace: multi-agent вместо одного промпта

Это был самый интересный момент разговора. Изначально я предложил классический подход — один LLM-вызов с большим промптом, который и анализирует визуал, и пишет сценарий. Получил жёсткое возражение от себя же:

«Не согласен, надо под каждый шаг свой агент с ИИ и узкозаточенным контекстом, и главный оркестратор-режиссёр, который общается со мной и передаёт им ТЗ.»

Это резко изменило архитектуру. Получилась команда узких агентов под управлением оркестратора:

• AI Аналитик сигналов — разбирает реферанс на части: хук, темп, монтажные приёмы, визуальные акценты, аудио.
• AI Режиссёр-оркестратор — общается с пользователем в чате, держит контекст проекта, маршрутизирует задачи.
• AI Сценарист — пишет адаптированный сценарий под нишу и TOV проекта.
• (В будущем) AI Монтажёр b-roll и AI Монтажёр финальной склейки — для второй фазы, когда вернёмся к видео-генерации.

Интерфейс при этом остаётся чистым: пользователь видит только сообщения от Режиссёра, под капотом — кооперация агентов. Trace всех вызовов пишется в БД для дебага, но в UI не показывается. Чтобы не объяснять пользователю, что такое «делегировал задачу sub-агенту».

Артефактом первого хода стала «карточка разбора реферанса» — структурированный JSON, который рендерится прямо в чате:

┌─ 🔍 Разбор реферанса ───────────────┐
│ 🎣 ХУК (первые 1.8 сек)             │
│   «Жилая недвижимость — это пассив» │
│                                       │
│ 🎬 ВИЗУАЛ                            │
│   Subject в центре кадра, статика   │
│   Цвет: тёплый, тёплое освещение    │
│                                       │
│ 📊 ПОЧЕМУ ЗАШЛО                      │
│   Контр-нарратив к мейнстриму...    │
└───────────────────────────────────────┘

Стек: что выбираем для MVP

Я запустил агента-исследователя с конкретной задачей — найти open-source кандидатов для chat-driven workspace с generative UI. Результат:

• assistant-ui (Yonom) для чат-UI — MIT, 10.2k звёзд, активно обновляется. Бесплатно.
• Mastra или AI SDK напрямую для backend-агентов — MIT.
• Supabase (самохостинг) для персистентности — свои таблицы threads, messages, artifacts, привязанные к project_id.
• Next.js 16 с App Router для фронта.
• Dokploy — наш стандартный путь деплоя через GitHub Actions + GHCR.

Видеоредактор с таймлайном (designcombo/react-video-editor) отложили — у него коммерческая лицензия за $1.5-3k, и сам блок видео-монтажа мы пока вынесли за рамки MVP.

По данным из git-истории за последние пять часов уже сделано: scaffold сервиса reels-pipeline-worker, схема SQL для Phase 0 с FK-связями и отложенными RLS-политиками, пустая страница таба и навигационная ссылка, дизайн-документ MVP и Feberra-референс.

Результат

По итогу нескольких сессий разбора и проектирования получилось:

1. Документация старого проекта на 631 строку с реальной фактурой по схемам, функциям и Trigger.dev запускам;
2. Чёткий список что переносим, что выкидываем — 60% оригинального кода уходит в архив;
3. Новая архитектура content-farm: Trend Watching + chat-driven workspace с multi-agent под капотом;
4. Скелет нового сервиса — reels-pipeline-worker уже scaffold'нут, схема Phase 0 написана, навигация добавлена;
5. Решённая дилемма стека — assistant-ui + AI SDK + Supabase вместо Convex/Trigger.dev.

Критично, что сама база старых сигналов нам уже не нужна — она была SaaS-историей, не нашей. Мы запускаем чистый pipeline с нуля, но с правильным лайфсайклом сигналов, который мы заимствовали из Feberra (SEED → SSN → SSN1 → SSN2).

Выводы

Первый урок — бэкапы старых проектов имеют ненулевую ценность, даже если код «навсегда выключен». У меня в архиве лежали не просто файлы, а целая модель данных, изученная боль и набитые шишки. Когда я открыл архив через год после shutdown'а, я фактически унаследовал команду экспертов в виде кода — и это сэкономило мне недели на повторных ошибках. Совет себе на будущее: при закрытии проекта всегда экспортируй полный snapshot БД и держи его рядом с кодом.

Второй урок — переосмысление контекста важнее переноса фич. Когда я разглядывал Feberra, было соблазнительно перенести всё — биллинг же работает, multi-tenancy же отлажена, лендинг тарифов готов. Но я остановился, спросил себя «а кому это сейчас продаётся?» — и оказалось, что мне самому. И это меняет 60% продукта. Никогда не переноси SaaS-обвязку в internal-tool, даже если она бесплатно достаётся.

Третий урок — multi-agent архитектура работает лучше одного жирного промпта, если задача распадается на узкие специализации. Я попробовал предложить один LLM-вызов «проанализируй реферанс и напиши сценарий» — и тут же получил возражение про потерю качества и консистентности. Когда задачи действительно разные (визуальный анализ vs. написание сценария vs. оркестрация диалога с пользователем), узкие агенты с собственным контекстом дают предсказуемо лучший результат. Сложнее в реализации, но это инвестиция, а не оверкилл.

Четвёртый урок — выкидывайте видео-таймлайн пока можете. Это самая соблазнительная фича для AI-видео-проектов и самая дорогая в реализации. Каждый раз когда я слышу «давай добавим видеоредактор» — я вспоминаю про лицензию за $1.5-3k и месяцы работы по интеграции Remotion, и откладываю. MVP может прекрасно жить с «вот тебе сценарий, иди сними сам». А там, глядишь, через полгода и без видеоредактора всё работает.

И последнее — chat-driven workspace это новый стандарт UX для творческих AI-инструментов. Я уже не верю в классические step-by-step wizard'ы для генеративных задач. Когда AI ведёт диалог, пользователь не теряется на третьем шаге, не пытается «нажать назад», не закрывает страницу с фразой «слишком много полей». Diff между классическим wizard и chat-driven — это разница между «заполняешь форму» и «беседуешь с экспертом». И второй вариант пользователи выбирают каждый раз. Если будете строить внутренний инструмент для команды — попробуйте chat-driven подход через assistant-ui, это стоит вечера на эксперимент.