Vantage
Custom admin dashboard
An admin built around how your business actually runs
Speculative scenario: Vantage is a polished B2B subscription tool — the frontend is solid, but the admin is three plugins duct-taped together. Checking a user's payment status means opening four tabs. Sending a notification means logging into a third-party tool. Toggling a feature means editing a config file. This is the inflection point most growing products hit: the frontend is good, but the admin is still the engineer's backyard.
Good admin design starts from business workflows, not database schemas. Two common scenarios: (1) an existing frontend that needs a proper admin for non-technical operators; (2) a new SaaS being built from scratch, admin scope planned from day one. Either way, the structure breaks into three layers: overview metrics (so the owner understands their numbers), member control (status, plan, and messaging in one screen), and module configuration (the owner adjusts features and rules themselves — no engineer required).
Every user's status, plan, and history — one screen
On a 3,000-user product, locating a specific user takes 4–6 steps on average. A well-designed member list puts search, filter, and status front-and-centre — cutting "what's going on with this user" from 5 minutes to 15 seconds. Pro / Free / Suspended readable at a glance; actions inline, no page jump.
Search is the primary action
The first thing any operator needs is almost always 'find this specific user.' Search bar sits front-and-centre in the header — not buried in a filter dropdown.
Status communicates through colour
Active / Suspended / Pending maps to green / red / yellow — no reading required to assess state. The operator gets a health-at-a-glance scan without reading every row.
High-frequency actions live inline
"Upgrade plan," "suspend account," "send message" — all inline in the row. No need to enter the user detail page just to find the button. Three clicks become one.
The owner adjusts features and rules — no engineer needed
Every client's admin needs are different. Some need LINE push, some SMS; some ECPay, some Stripe. Modular design means the owner uses toggles to control which features are live. Detail settings — trigger conditions, message templates, send limits — all configurable in the same screen without touching code.
Settings page is for operators, not engineers
Feature toggles, checkbox trigger conditions, plain-text message templates — not JSON, not code editors. Non-technical operators should be able to configure confidently without calling us.
Modules enable and disable independently
Client A needs LINE push but not SMS; client B needs Stripe but not ECPay. Modular architecture lets us deliver a different feature set to each client using the same admin framework — the admin grows with the business, not the other way around.
MRR, churn, plan mix — the numbers that drive decisions
The core of an enterprise admin isn't a management interface — it's letting decision-makers understand the business in 30 seconds. MRR trend shows growth trajectory, plan distribution shows upsell opportunity, top-paying accounts tell sales who to prioritise. Data is live, not a CSV export opened in Excel.
MRR over GMV
For a SaaS business, the health metric is MRR, not GMV or total revenue. MRR movement reflects the real trajectory of a subscription business. Put it front and centre so every time the CEO opens the admin, it's the first number they see.
Churn lives in the stats bar
Churn rate is the most ignored and most damaging number in a SaaS business. Put it next to MRR and growth rate — make it impossible to ignore. If it only lives inside a report somewhere, decision-makers will never voluntarily look at it.
Which feature burns the most tokens and costs the most — you need numbers before you can optimise
The most common problem after shipping AI features: the month-end bill is higher than expected, nobody knows which feature is eating the cost, and the Haiku/Sonnet ratio isn't optimised. The AI usage dashboard gives engineers and owners visibility: daily call volume by model, feature usage share, cost vs budget progress. The 62% cost saving over GPT-4o wasn't luck — it was a decision made from a screen like this.
Stacked bars split by model
Haiku and Sonnet have wildly different costs — the same feature costs 80% less on Haiku. Stack both models in the same bar in different colours, and an engineer immediately spots the day Sonnet calls spike unexpectedly and can investigate before the next billing cycle.
Budget tracker lives in the sidebar
Put the monthly cost vs budget progress bar in the sidebar permanently, not buried in settings. Every time someone opens the AI usage page, they see '61% used' — so a cost anomaly gets caught while there's still time to react.
What this build would use
- Next.js 15
- Tailwind CSS
- Supabase (PostgreSQL)
- NextAuth / Lucia
- LINE Messaging API
- Resend
- ECPay / Stripe
- Vercel