Protocol 14 of 18Track, BuildingWhat we ship

Admin interfaces and dashboards

Building internal tools (a CRM, an admin UI, the Monday dashboard) so the team can read and act on the data without escalating to engineers. Synthetic data so you can see it full before the real data arrives.

← All 18 protocols
Protocol 13Communications, email, nurture, ResendAll 18Protocol 15Agents in the cloud
Why this matters

The pain it
solves

A team can have the cleanest workflows, the best agents, and a working database, and still grind to a halt if the only way to see the data is through the Supabase dashboard. Admin interfaces are how non-engineers on your team read, write, and act on the data your product collects.

This is also the protocol that retires the last surviving piece of the old CMS instinct. The admin UI is the new editor. You built it. You own it. It looks like your site and works like your team.

The teaching

What this
actually is

What an admin interface actually needs

A team can have the cleanest workflows, the best agents, and a working database, and still grind to a halt if the only way to see the data is the Supabase dashboard. Admin interfaces are how non-engineers read, write, and act on the data your product collects.

At minimum, an admin UI has four parts. Get these four and you have a real product, not a database with a paint job.

  • A protected route
    Auth required. /admin behind a login. Even on a tiny project: lock it on day one, not when the data leaks.
  • Tabular views
    Lists of leads / customers / orders pulled live from Supabase. Sortable. Filterable. The single screen the team opens 50 times a day.
  • Inline actions
    Update status, send email, archive a row without leaving the page. Every leave-the-page click costs five seconds and one context switch. Inline saves both.
  • Drill-down detail
    Click a row, see the full record, edit it, see related rows. The detail view is where the work actually happens.

The trap to avoid

Most admin UIs look nothing like the customer-facing site. Default Bootstrap. Default Material UI. A different brand entirely.

When admin looks like a different product, your team mentally separates the brand from the data. That separation costs you taste. The team starts treating the customer-facing site as marketing and the admin as work, and the work that touches customers gets less care over time.

Rule: same design system. Same fonts, same colors, same component library. Admin is a different surface of the same product.

A good admin interface is boring

Boring fonts. Boring layout. Tons of whitespace. Information dense but not cluttered. The data is the point.

Resist the urge to design it. The team is here to do work, not to admire your gradients.

Synthetic data: see it full

An empty system looks like nothing, and you cannot design a dashboard against three test rows. Before you build the Monday view, fill the database with realistic synthetic data shaped by your own interview answers: your inquiry types, your stages, your products.

  • Flag every row
    An is_synthetic column on every table, default false. Every seeded row is true. That flag is what lets you delete it all in one command when the real data arrives, and what stops the nurture cron and the agent from ever touching a fake person.
  • Ninety days, weighted recent
    Dates spread across the last quarter, more recent ones heavier. A fixed random seed so re-running gives the same data. The dashboard needs the spread; three rows dated today tell you nothing.
  • A delete script next to the seed script
    scripts/delete-synthetic.ts removes every flagged row and prints the counts before and after. You do not run it at the retreat. You run it at home, the day your real contacts load.

The Monday view

This is why you seeded data: now you can build the page you will open every Monday. Six numbers a founder actually acts on, read straight from the database, in your design system, with no new charting library. Volume, pipeline, conversion, revenue, mix, list size.

Every number clicks through to the filtered list it came from. When the real data comes in, the page does not change, only the numbers do. Sit with it for five minutes and note which number you would act on. That is the one to make bigger.

Try it yourself40 minutes

Build a working /admin in 40 minutes

You need the lead capture from Protocol 07 (with the contacts table). You will add a protected /admin route, a leads view, and one inline action.

  1. Step 01
    Add Supabase Auth (email + password)

    In Claude Code: "Add Supabase Auth with email + password. Create a /login page and a sign-up flow. Restrict /admin to logged-in users only." Sign up as yourself.

  2. Step 02
    Build the leads table at /admin

    Tell Claude: "At /admin, fetch all rows from contacts using the Supabase server client. Render them in a table: name, email, created_at, status. Use the existing design tokens."

  3. Step 03
    Add filter and sort

    Tell Claude: "Add a search field that filters by name or email. Add column sorting on created_at and status."

  4. Step 04
    Add an inline status action

    Tell Claude: "Add a status column with values New, Working, Closed. Make it editable inline with a dropdown. Save the change to Supabase on change. Show a toast on success."

  5. Step 05
    Test it end to end

    Submit a fake lead from your homepage. Log in to /admin. See the lead. Change status from New to Working. Reload. Status persisted.

  6. Step 06
    Seed synthetic data and add one dashboard number

    Tell Claude: "Add is_synthetic to contacts, write scripts/seed-synthetic.ts for 80 believable contacts over 90 days, run it, then add /admin/dashboard with one panel: new contacts per week for 12 weeks, as bars, each bar clicking through to the filtered list."

Outcome

A real /admin route on your live site with auth, a filterable leads view, one working inline action, ninety days of flagged synthetic data, and the first panel of your Monday view. Your team can now read and act on the data without you. The product has a back office.

Official resources

Straight from
the source

Supabasedoc
Supabase Auth with Next.js
Next.jsdoc
Next.js Route Handlers
Next.jsdoc
Next.js Middleware (proxy)
What you walk out with

By the end of this
protocol

At the retreat

You learn it by
doing it

You build a working CRM page in 40 minutes that lists, filters, and updates the leads from your contact form. Then you secure it with login so the data is actually private.

Saigon, Jun 20See all 18 protocols
Connects to

Other protocols this
compounds with

Protocol 07
Supabase basics
Protocol 12
Design systems
Protocol 16
Harden the code
← Previous, Protocol 13
Communications, email, nurture, Resend
Next, Protocol 15 →
Agents in the cloud