12 вкладок каждое утро: почему это не работает
Каждое утро начинается одинаково. GA4, Ads Manager, Supabase Dashboard, Telegram, почта, CRM. Fortune в январе 2026 написал про это прямо: даже топовые CEO первым делом хватают телефон и перебирают приложения по одному. У меня это было 6-12 переключений до первого решения дня.
Проблема не в количестве инструментов. Каждый из них отлично показывает свой кусок картины. Проблема в том, что никто не показывает целое. Нет единого сигнала «всё ок» или «вот тут горит». Ты переключаешься между вкладками, собираешь пазл в голове и надеешься, что ничего не забыл проверить.
Для соло-фаундера с AI-агентами добавляется совершенно новый слой боли. Агент упал в три ночи, cron отработал с exit code 0 но ничего не сделал, OAuth-токен протух. И ты узнаёшь об этом через пять дней. У меня был такой инцидент: компонент GoogleTagManager лежал в layout, но переменная NEXT_PUBLIC_GTM_ID не была добавлена в Vercel ENV. GTM молча не загружался 5 дней. Обнаружил только когда полез проверять данные для командного центра. Пять дней без аналитики, и никто не заметил.
Готовые SaaS-дашборды типа Databox, Cyfe, Geckoboard берут $200/мес и покрывают процентов 30 от того что реально нужно. По данным Retool Build vs Buy Report 2026, 35% компаний уже заменили хотя бы один SaaS на кастомную сборку. Потому что быстрее собрать самому, чем ждать когда вендор добавит нужную интеграцию.
Что такое командный центр фаундера и чем он отличается от дашборда
Дашборд показывает метрики. Конверсии, CPL, трафик, выручка. Командный центр показывает здоровье всего бизнеса: продукты, инфраструктура, агенты, реклама, аналитика в одном месте, с одного взгляда. Разница как между панелью приборов в машине и диспетчерской на электростанции.
Ключевой примитив, который делает это возможным, называется heartbeat. Это не uptime-мониторинг сервера. Это пульс жизни каждого компонента бизнеса: MCP-сервер, SEO-агент, cron-задача, Telegram-бот, OAuth-токен. Каждый компонент шлёт ping раз в N минут. Если ping свежий, кружок зелёный. Опаздывает, жёлтый. Не пришёл, красный. Всё.
В enterprise-мире это называют «single pane of glass» и строят под это NOC-комнаты с шестью мониторами и дежурной сменой. В 2026 это одна вкладка Next.js с auto-refresh каждые 45 секунд. Серьёзно, всё что нужно: таблица в Supabase, один RPC для ping, компонент AutoRefresh на клиенте и router.refresh() по таймеру.
Важный момент: командный центр видит только фаундер. Это не продуктовый UI, не дашборд для команды и не отчёт для инвестора. Это нервная система бизнеса, к которой подключен один человек. Owner-only guard, e2e авторизация, никаких шеренных доступов. Изоляция данных строится на тех же принципах, что и multi-tenant RLS в Supabase, только тут «тенант» один, и это ты сам. Обкаточная площадка, где можно экспериментировать не мешая продуктам на фронте.
Архитектура: Next.js + Supabase + один монорепо
Стек максимально простой: Next.js 16 (App Router), Tailwind CSS v4, Supabase (PostgreSQL + RLS), деплой на Vercel. Ни одного дополнительного фреймворка для дашбордов. Все API-интеграции (Meta Ads, Google Ads, GA4, GTM) написаны на чистом fetch без внешних пакетов. Google Ads, например, я в какой-то момент переписал с пакета google-ads-api@23 на чистый REST v22, выкинув 1378 строк зависимостей, потому что пакет упирался в устаревший v17 и глотал ошибки.
Командный центр не отдельный проект. Это route group /command внутри того же монорепо milakhin-studio, рядом с продуктами M.Sight и M.Flow. Общие компоненты, общая БД, общий деплой. Не нужно держать отдельный инстанс, не нужно синхронизировать данные между проектами. Всё в одном Next.js-приложении, один vercel deploy.
Слева сайдбар 256px с 10 вкладками: Дата-центр (главная с heartbeat и блоком каналов за 30 дней), SEO Room (3D-офис), Digital Room (задачи агентам через очередь), Заявки, Реклама (Meta + Google Ads), Аналитика (GA4), SMM (7 IG-аккаунтов), M.Sight, M.Flow, Что поесть. Начинал, кстати, с горизонтальной шапки с 9 вкладками. Через 3 дня после запуска стало криво масштабироваться, переехал на сайдбар. Типичная история: начинаешь с простого, быстро упираешься в потолок, перестраиваешь.
Компонент AutoRefresh это client-island: обёртка которая вызывает router.refresh() каждые 45 секунд. Heartbeat-статусы обновляются без перезагрузки страницы. На экране тикает индикатор «обновлено Xс назад». Никаких WebSocket, никакого polling API. Next.js App Router и React Server Components делают всю работу: серверная функция заново читает данные из Supabase, React сравнивает DOM, обновляет только изменившееся.
Heartbeat-система: одна таблица вместо Datadog
Вся система мониторинга укладывается в одну таблицу studio_heartbeats (миграция 097) и одну RPC-функцию studio_heartbeat_ping. Компонент шлёт ping с именем сервиса и меткой времени. Панель читает свежесть каждого пульса и показывает светофор.
Что конкретно пингует прямо сейчас: MCP-сервер студии раз в минуту, cron-задачи при каждом запуске, SEO-агенты на каждом этапе 14-шагового пайплайна, Telegram-боты по свежести данных. Новый сервис подключается за две минуты: импортируешь pingHeartbeat() из lib/heartbeat.ts, вызываешь в нужном месте, добавляешь строку в панель.
Принцип, который я зафиксировал в коде комментарием: падение пульса НИКОГДА не ронит основную работу. Все ошибки heartbeat-системы глотаются и логируются. Heartbeat это наблюдатель, не участник. Если Supabase лежит, MCP-сервер продолжает обслуживать запросы, просто кружок на панели станет красным.
Для соло-фаундера с 5-10 агентами enterprise observability (Langfuse, Braintrust, Datadog) это overhead ради overhead. Месяц настройки, $50-200/мес подписки, алерты на каждый чих. Одна таблица в Supabase (free tier) плюс светофор на панели дают 100% покрытие того что мне реально нужно знать. По данным Gartner, у 50% проектов с AI-агентами до сих пор нет production-grade мониторинга. У соло-фаундера задача проще: мониторь 10 компонентов, не 10 000. И для десяти компонентов хватает одной таблицы.
Что я вижу каждое утро: 10 виджетов и зачем каждый
Первое что я проверяю утром, это heartbeat-панель. Зелёный/жёлтый/красный по каждому сервису. Если всё зелёное, можно спокойно двигаться дальше. Если красное, сразу понятно где копать. Вся проверка занимает 3 секунды, вместо открытия 5 вкладок по одной.
Сверху главной страницы блок «Деньги»: MRR, Spend за 30 дней, заявки, количество клиентов. Не vanity metrics типа «уникальных визитов», а unit economics одного экрана. Рядом, полоса клиентов с первым риском каждого: у кого падает CPL, у кого заканчивается бюджет, у кого давно не обновлялись креативы.
Вкладка «Реклама» показывает Meta + Google Ads за 30 дней по всем клиентам: CPL, spend, leads. Без захода в Ads Manager. Раньше я открывал каждый рекламный кабинет отдельно, теперь одна таблица. SMM-пульт мониторит 7 Instagram-аккаунтов: от Gate City (30K подписчиков) до FlyBox (300 подписчиков). Комменты с inline-ответом прямо из панели, IG Direct с перепиской, engagement-метрики на карточку каждого аккаунта.
Отдельная вкладка, которую показывать людям чуть неловко, потому что она выглядит как игрушка: SEO Room. Это 3D-офис на three.js с воксельными человечками. Шесть AI-агентов моего SEO-отдела визуализированы как маленькие фигурки за рабочими столами. Когда агент работает, он сидит за столом и печатает, мониторы пульсируют. Когда закончил, уходит в зону отдыха: один барабанит за ударной установкой, другой играет в настольный теннис, третий спит на диване. Всё в реалтайме через Supabase-подписку. Это не просто визуализация ради красоты. Я одним взглядом вижу: два агента работают, четыре отдыхают, значит пайплайн на середине.
AI-агенты как сотрудники: 3D-офис и очередь задач
SEO-пайплайн работает по cron: понедельник, среда, пятница в 04:00 по Алматы. 14 этапов, 6 агентов. У каждого есть имя и зона ответственности. Они публикуют длинные гайды на блог в моём голосе, без утечки конфиденциальной информации. За это отвечает Confidentiality Firewall: отдельный агент с файлом forbidden.yaml, который проверяет каждый текст перед публикацией. Подробнее про весь конвейер я писал в посте про автономный SEO-отдел, там разобран каждый из 14 этапов.
Digital Room работает по другому принципу: задачи через очередь digital_tasks в Supabase. Worker-скрипт на моём маке поллит очередь, запускает Claude Code CLI под Max-подпиской (без pay-per-token, без счетов от Anthropic), парсит action-блоки из ответа агента. Статусы задач простые: pending, needs_approval, done, failed. Аналитик GA4 уже работает: принимает задачу «покажи трафик за неделю», гоняет агента, возвращает результат.
Фундамент всего этого, MCP-сервер студии с 29 инструментами. Meta Ads, Google Ads, GA4, GTM, M.Flow. Из Claude Code я спрашиваю «покажи трафик milakhin.studio за вчера» или «сколько активных юзеров сейчас», и получаю ответ без единого клика по Ads Manager или GA4. Это стратегическая ставка: MCP-сервер сегодня это удобство, завтра это фундамент для полностью автономного рекламного агента. Агент утром читает GA4 + Google Ads + Meta insights, сверяет CPL по каналам с ROI из M.Flow, предлагает что выключить, где поднять бюджет, что бустить.
Мониторинг AI-агентов как сотрудников, это пустая ниша. Gartner и Kore.ai пишут про «agent management platforms» в абстрактном ключе. Но никто пока не показал это как буквальный офис с человечками, которые работают и отдыхают в реальном времени. SEO Room, возможно, первый публичный пример такого подхода.
Инциденты которые окупили всю затею
Пять дней без GTM и GA4. NEXT_PUBLIC_GTM_ID не была добавлена в Vercel ENV после подключения компонента. GTM молча не загружался, данные не собирались. Обнаружил случайно, когда полез проверять аналитику для командного центра. Урок: без мониторинга silent failure живёт днями, и ты об этом не подозреваешь. После этого первое что я делаю при подключении любого NEXT_PUBLIC_*, это проверяю vercel env ls.
Мёртвый Meta-токен в MCP-сервере. Все meta_* tools падали с кодом 190 «Application has been deleted», хотя приложение было живо. Оказалось, протух токен именно в packages/mcp-studio/.env, а рабочий лежал в корневом .env.local под другим именем: META_ACCESS_TOKEN vs META_ADS_ACCESS_TOKEN. Три места хранения одного секрета, три точки рассинхрона. Та же болячка, что с Google Ads client_secret, который тоже живёт в трёх местах и регулярно рассинхронизируется.
Аргумент «не трать время на инфру, делай продукт» не работает когда cron падает на 6 часов молча. Первый предотвращённый инцидент окупает неделю разработки мониторинга. По аудиту dev.to (2026), 9 из 12 соло-фаундеров не имели inter-step assertions в агентных пайплайнах. Практический опыт работы с агентами в продакшене показывает одно и то же: без мониторинга AI-агенты остаются чёрным ящиком, и ты узнаёшь о проблемах постфактум.
Как начать свой: минимальный стек за выходные
Минимум: Next.js App Router + Supabase (free tier) + одна таблица heartbeats + RPC для ping. Деплой на Vercel. Итого $0.
Первый виджет: heartbeat-панель. Научи каждый cron, агент и бот делать ping при старте. Если ping старше N минут, жёлтый. Старше 2N, красный. Одна SQL-таблица, один вызов upsert, один компонент на фронте.
Второй виджет: ключевые метрики бизнеса. Один SQL-запрос, одна карточка. Не строй дашборд мечты, строй один экран с ответом на «всё ок?». Если ведёшь рекламу, подтяни spend и CPL. Если SaaS, подтяни MRR и churn. Один запрос, одна цифра, одна карточка.
Owner-guard: middleware проверяет is_platform_owner. Командный центр не для команды, для тебя. Один флаг в базе, одна проверка в middleware, весь route group закрыт.
Эволюция неизбежна: от шапки к сайдбару за 3 дня, от 3 виджетов к 10 за месяц. Начни с малого, расти от боли. Каждый новый виджет появлялся потому что я что-то проворонил без него. Не потому что «было бы круто добавить». Боль, виджет, меньше боли. Повторить.