Admin dashboard за 2 тижні — що будували, що переробили, що залишилось

2 тижні від порожнього Next.js маршруту /admin до робочого dashboard з 6 секціями, реальними бекенд-ендпоінтами і live-даними. Не ідеального — робочого. Це різні речі, і різниця між ними коштувала мені кількох конкретних рішень.

Розкажу що будував, що свідомо пропустив, що виявилось неправильним і що з цього варто взяти якщо ти будуєш SaaS один.

Контекст: навіщо взагалі admin dashboard

Admin panel у Leadmlyn вирішує дві різні задачі, і важливо не змішувати їх в одній голові.

Перша — операційна підтримка: я як засновник маю бачити стан клієнтів, балансів, ботів і сесій без того щоб лізти в базу даних напряму. Якщо клієнт пише «мій бот не відповідає» — мені треба за 30 секунд зрозуміти що відбувається: webhook живий чи ні, wallet не нульовий, модель не залочена.

Друга — бізнес-аналітика: конверсія trial→paid, середній ARPU, активні сесії за тиждень, churn rate. Це KPI від яких залежить де я витрачаю час.

Обидві задачі треба вирішити одним dashboard. І це перше місце де треба приймати рішення: що для MVP, що для v2.

Що побудували за 2 тижні

Я розбив dashboard на 6 bucket-секцій і йшов по них послідовно.

Bucket A — Users і Sessions. Список користувачів з фільтрами, детальний профіль: тариф, wallet-баланс, статус підписки, дата реєстрації. Дії: скинути пароль, примусовий вихід, призупинення акаунту, видалення за розкладом. Список активних сесій з KPI по lockout і failed-login. Це пріоритет номер один — без цього неможлива підтримка.

Bucket B — Bots і KB. Список ботів з прив'язаними командами і якістю KB. Ендпоінти для CRUD ботів, entities, шаблонів, системи модерації. Тут найбільше поверхні — KB-редактор, якість відповідей, налаштування тону.

Bucket C — Контент. Адміністрування блогу: список постів, редактор з pillar-checkbox і розкладом публікації, завантаження cover-зображень через MinIO. Це bucket що я майже не торкав два тижні — blog content engine почався пізніше.

Bucket D — Платежі та конфігурація. Wallet-транзакції по всіх акаунтах, список платежів з replay-signature і ручною реконсиляцією, список інтеграцій з webhook-events. Tier-configs і markup-rules — можливість змінити маржу і тарифні ліміти без деплою. Це bucket де живе гроші і де ціна помилки найвища.

Bucket E — Бекенд-сервіси. Registry моделей, feature-flags, файлова система. Тут я свідомо зупинився на мінімумі — перемкнути флаг і переглянути стан файлів.

Bucket F — Аналітика і здоров'я. Workers health-check, аналітика, changelog, site pages. Overview-ендпоінт що повертає повний KPI-set для dashboard: активні боти, trial-акаунти, wallet-завантаження, conversion metrics.

Що свідомо пропустив для v1:

Що довелось переробити

Overview-ендпоінт. Перша версія повертала тільки 4 лічильники. Dashboard чекав на повний KPI-set — активні боти, trial-конверсія, wallet-навантаження, retention-метрики. Довелось переписати /admin/overview щоб він повертав всі дані що потрібні dashboard без зайвих запитів.

Wallet top-up validation. Перша версія ендпоінту /admin/wallet/top-up повертала 422 при порожньому reason-полі без зрозумілого повідомлення. Клієнт — тобто я — не розумів що не так. Виправили: явна валідація з описом, toast в UI.

Niche edit by slug. Спочатку редагування ніші йшло за числовим ID. Виявилось що в URL і в інших контекстах ніша живе як slug, і конверсія між ними в декількох місцях — зайва складність. Переробив на slug-first підхід.

trial_to_paid_pct > 100%. Це вже класика: перша версія не мала верхнього обмеження, і при ручному тестуванні метрика показала 140%. Тепер clamp до 100%.

Помилки не катастрофічні — але кожна з них забирала від 30 хвилин до 2 годин. В сумі це кілька днів що пішли на виправлення речей які можна було передбачити.

Що dashboard вміє зараз

На сьогодні working dashboard включає: повний CRUD по акаунтах і командах, live wallet-баланс і транзакції для всіх акаунтів, tier-конфігурацію без деплою, список ботів з webhook-статусом, Bucket D для платіжних операцій і реконсиляції, Overview KPI для щоденного моніторингу.

Що не готово: аналітичні часові ряди, bulk operations, детальний аудит-лог дій адміна, role-based access для майбутньої команди.

Детальніше про те що показує клієнтська частина dashboard — в матеріалі «Аналітика розмов: що бачить власник у dashboard».

Wallet-частина dashboard пов'язана з рішенням про передоплату — про те чому обрали prepaid-модель читай в «Wallet-модель Leadmlyn: чому передоплата».

Уроки для соло-засновника

Scope не «мінімальний» — scope «достатній для підтримки». Перший критерій для MVP admin panel: чи можу я відповісти на запит підтримки за 2 хвилини. Не «чи є всі фічі» — а «чи не мушу я лізти в термінал для базових операцій». Все решта — v2.