Why Public and Admin Never Share State in This Portfolio
The real benefit of splitting public and admin wasn’t security - it was that neither side has to think about the other.
When I built this portfolio's own CMS, the obvious structure was one Next.js app with a public site and an admin dashboard living side by side — which is exactly what I did. The part that mattered more than the file structure was a rule I kept from day one: the public site and the admin panel never share client-side state, not even the theme.
Two Layouts, Two Contracts
The public pages and the admin pages sit under separate route groups, each with their own layout, their own data-fetching, and their own assumptions about who's looking at the page. Public pages assume an anonymous visitor and fetch published content only. Admin pages assume an authenticated, authorized user and fetch everything - drafts included - behind a Firebase Auth check.
Mixing those two of concerns in one layout is tempting early on, because so much looks similar: both render a header, both show projects and artwork. But "looks similar" isn't "is the same." The moment public rendering logic has to branch on "is this an admin preview," every public page becomes slightly harder to reason about, and every admin feature risks leaking into a bundle that anonymous visitors download.
What It Actually Saved
Keeping them separate meant I could change the admin dashboard's entire design system — fonts, card styles, even the liquid-glass theme - without touching a single public-facing component, and vice versa. It also meant a bug in a draft blog post's admin editor couldn't possibly affect what a real visitor sees, because the public API layer never has a code path that returns draft content.
The cost was some duplication - two header components instead of one, two sets of data-fetching hooks. I'd pay that cost again. Shared abstractions between two things with genuinely different trust boundaries tend to become the place bugs hide, not the place complexity goes away.