The Problem
Everything lived somewhere different
A modeling agency was managing models, jobs, documents, and money across scattered messages and files. Availability lived in one thread, paperwork in another, and invoices somewhere else again.
There was no single place where an admin, an event creator, and a model could each see what they needed, and nothing else. That gap is where bookings get double-checked by hand, documents go missing, and follow-ups depend on someone remembering to send them.
The fix was not another spreadsheet. The agency needed one source of truth with rules about who can see what; a model should see their own jobs and paperwork, an event creator should see the events they run, and only the admin should see the full roster, the documents, and the money.
That permission structure is the heart of this build, and it is the part most template dashboards skip.
What Was Built
A dashboard with a real backend
A web dashboard backed by Supabase for account creation, data, and multimedia storage of model photo galleries, with role-based access so admins, event creators, and models each get a different view of the same system. The admin side is organized into seven sections; the model side is a separate portal with its own layout, covered below. The interactive demo opens on the admin side with an ADMIN / MODEL toggle, so both layouts can be compared in one place.
MANAGEMENTWORLDWIDE
Inside the Admin View
Seven sections, one source of truth
Models
A searchable photo-tile grid of the roster, filterable by status: active, inactive, unavailable, on hold, and exclusive. Opening a model brings up tabbed detail, including a client-facing comp-card preview and private notes that stay internal only; clients never see them.
Clients
The agency’s client list, with search and client creation, kept beside the bookings those clients generate.
Documents
Paperwork tracked by model, type, status, and upload date, including work permits, ID documents, and contracts, with missing and approved states visible at a glance. A document review queue puts submissions waiting on a decision in one place, so approvals do not stall in an inbox.
Bookings
Every booking in one list, filterable by pending, accepted, declined, awaiting response, and cancelled. The booking form starts from the client rate, applies the commission, default 20 percent, and derives the model’s rate automatically; no one does that math by hand.
Calendar
A month grid with previous and next controls and an all-models filter, so the whole schedule can be read in one view. When a new booking would clash with an existing one, the calendar flags the possible double-booking before it becomes a problem.
Finance
Summary cards for booked, invoiced, paid, unpaid, overdue, and pending amounts, plus commission and amounts owed, a revenue chart, and CSV export.
Invoices
Invoices tracked by invoice number, client, total, paid, due, and status, so what is owed is never a guessing game. Each invoice moves through a full lifecycle, from drafted to paid, and partial payments are recorded against the balance rather than handled off the books.
Notifications
A notifications bell on every admin page, alongside sign out, so new activity surfaces without anyone digging for it.
Photo galleries
Model galleries stored in Supabase multimedia storage, attached to each model’s profile rather than scattered across drives and threads.
Inside the Model View
The model portal: their work, in their layout
The model side is not a trimmed copy of the admin console. It is a centered, top-bar portal built around one person’s own work, with eight areas of its own: Home, Profile, Gallery, Bookings, Calendar, Earnings, Documents, and Preferences. A model sees their next booking and what still needs their attention the moment they sign in; they never see the roster, the agency’s finances, or another model’s anything.
Home: what a model sees on sign-in
Calendar: their own bookings, laid out by day
What needs them, first
The portal opens on the next booking, any pending requests waiting on their response, and their profile completion, so the important things are never buried in a menu.
Answer in the booking itself
Each booking carries its own message thread. They can accept, decline, ask for clarification, or flag a conflict; the conversation stays attached to the job it belongs to.
Their schedule, by the day
Their own bookings on a month calendar, one tap from each booking’s details. A gold marker shows when two bookings land on the same day, so a clash is visible before the day arrives.
A checklist, not a chase
Required documents appear as a checklist with upload built in, matching the follow-up emails the system sends; they always know exactly what is still outstanding.
Their money, summarized
An earnings summary covers their own bookings only. The agency-wide finance picture stays on the admin side, where it belongs.
Control over every photo
Gallery controls let them manage their images, with badges marking which photos are primary, which are public, and which are internal only.
Notifications on their terms
Notification preferences let them choose how the system reaches them, so booking alerts and document prompts arrive the way they will actually see them.
The Booking Workflow
From event created to calendars synced
This loop is the working core of the dashboard. It was tested across roles by the builder, end to end, with mock data.
-
1
An event is created
An admin or an event creator creates an event in the dashboard and assigns it to a model.
-
2
The model is notified twice
The model receives an email about the upcoming job and a notification on the site itself, so the booking does not depend on a single inbox being checked.
-
3
Acceptance syncs both calendars
When the model accepts, the event populates the model’s calendar and the admin’s calendar at the same time. One acceptance; both sides stay in sync.
-
4
Documentation is chased automatically
Follow-up emails prompt the model for any documentation the job needs, instead of the admin remembering to ask by hand.
-
5
Files land on the model’s side
The admin can attach files, such as blank contracts, directly to the model’s side of the dashboard, so paperwork travels through the system rather than through loose messages.
Permission Structure
Three roles, three different dashboards
Admin
The full operation in one view.
- All seven sections: Models, Clients, Documents, Bookings, Calendar, Finance, Invoices
- Full roster, document statuses, and the money picture
- Creates events and attaches files to a model’s side
Event creator
Enough to run events; nothing more.
- Creates events and assigns models
- Triggers the same email and site notification to the model
- Does not get the admin’s finance and roster-wide view
Model
Their own work, and only their own work.
- A top-bar portal of their own: Home, Profile, Gallery, Bookings, Calendar, Earnings, Documents, Preferences
- Receives job notifications by email and on the site; accepts, declines, asks questions, or flags conflicts inside each booking
- Works a document checklist with upload, manages their gallery, and sets their own notification preferences
- Gets files, such as blank contracts, attached to their side by the admin
Proof and Current Status
What is verified, stated plainly
Everything observed inside the dashboard during review was mock data. The system, roles, workflow, and finance tracking are shown working end to end; no live agency volume or revenue is claimed anywhere in this case study, because there is none in the data reviewed.
How it was checkedThe admin screens were observed directly in a read-only review of the live dashboard. Both sides of the system were then reviewed in the interactive demo at h1demo, which is entirely mock: the admin console, including model detail tabs, the document review queue, commission handling, conflict flagging, and the invoice lifecycle; and the model portal, including booking responses, per-booking messaging, the document checklist, earnings, and gallery controls. The cross-role workflow was also tested by the builder across the admin, event creator, and model layouts. No individual names or financial totals from the demo are published here.
The stack
- Backend
- Supabase: account creation and auth, database, multimedia storage
- Access
- Role-based permissions for admin, event creator, and model accounts
- Messaging
- Email plus on-site notifications for jobs and documentation
- Calendar
- Accepted events sync to the model’s and the admin’s calendars
- Finance
- Summary cards, revenue chart, CSV export, invoice tracking
- Try it
- maywood.enterprises/h1demo; the interactive demo, entirely mock data
Outcome, in Progress
A working system, and a door opened
The dashboard was built right before a period of travel, and it did what a portfolio piece is supposed to do: it showed the work. On the strength of it, the agency is considering Maywood Enterprises a partner in the modeling management business, essentially retained, with the return on the build to follow once the dashboard is handed over and fully applied in the agency.
That part is stated here exactly as it stands: in progress, not yet a completed retainer. Full delivery and rollout are still ahead, including the handoff of the website and attaching the dashboard to the agency’s own site. When that lands, this case study gets one new line; the partnership, in writing.
For any other small business reading this: the pattern travels. Models become customers, bookings become jobs, documents become paperwork; the point is one system with the right permissions instead of scattered messages.
Take the case study with you
The PDF carries the same text as this page, formatted for attaching to an application or sending to a client. Or skip the reading and walk the system yourself in the interactive demo; it is entirely mock, so click anything.