The Admin Panel Nobody Sees
5 April 2026

When you show a product, you show the app. The screen users see, the flow you polished, the animations you spent too much time perfecting.
You don't show the admin panel. It doesn't make it into case studies, doesn't appear in portfolio screenshots, isn't the thing you talk about when someone asks what you're working on. It's backstage — and like all backstages, it's what determines whether the show goes on or not.
What an Admin Panel Actually Is
For ReD Sposi, the admin panel is a separate React + Vite application, deployed on a subdomain, accessible only to me. From there I manage everything guests can't do themselves:
- Create and manage invite codes
- See who has RSVPed and with what preferences
- Approve photos and videos before they appear in the gallery
- Manage the betting game questions
- See real-time logs of what's happening in the app
For Gestionale Molinari, the "admin panel" is the entire application — it's an internal tool by definition. For Barba Studio, it's the section reserved for shop owners to manage their barbers, schedules, and bookings.
Every product has one. None of them are alike because no product has the same operational needs.
Why React + Vite and Not Next.js
For landing pages and public sites I use Next.js — server-side rendering, SEO, and file-based routing make sense there. For admin panels, they don't.
An admin panel is almost always a single-session interactive application. It doesn't need SSR because it won't be indexed. It doesn't need sophisticated page transitions. It needs to be fast to build, fast to load, and easy to iterate on.
Vite + React in SPA mode is the simplest choice that works. The build takes seconds, the dev server is instant, and there's no routing abstraction to fight — I use React Router directly, which for an admin application is more than enough.
Design When the User Is You
Building an admin panel for personal use has a peculiar characteristic: you're both the designer and the user at the same time.
This sounds like an advantage — and partly it is. No user research, no hypothesis validation, no usability testing. You already know what you need.
But it has a risk too: building for you-who-knows-the-system, not for you-who-forgot-how-it-works-six-months-ago. I know every field, every state, every possible action in the ReD Sposi admin panel. I'll use it intensively for a few weeks, then disappear for months, and reopen it the day before the wedding trying to remember how to approve a video.
For this reason I invested more than expected in clear labels, confirmation messages, and empty states that explain what to do. Not for users — for future me, who won't remember anything.
The Invisible Thing That Enables Everything
There's one feature in the ReD Sposi admin panel I've used more than any other: the guest list with RSVP status.
It sounds trivial. It's a table with names, codes, and checkboxes. But without that table, I wouldn't know who confirmed their attendance, who needs to be contacted, who chose the vegetarian menu, who requested the shuttle. That table is the difference between organizing a wedding with real information and organizing it with guesses.
No guest will ever see that screen. It's the kind of thing that doesn't exist in mockups, isn't shown in demos, and doesn't appear in any presentation video. Yet it's the feature I use most.
Building Tools for Yourself
There's something liberating about building tools only you will use.
No need to justify design choices to anyone. No need to explain why you put that button there and not there. No compromise between what you want and what the client thinks.
The only standard is: does it work for me? Does it solve the problem I had? When I come back here in three months, do I still understand what's happening?
If the answer to these questions is yes, the admin panel succeeded. It doesn't matter if it's beautiful, it doesn't matter if it uses Tailwind more orthodoxly, it doesn't matter if the architecture is "correct."
Backstage doesn't need to be photogenic. It needs to work.