I've been staring at my portfolio architecture and realizing how fragmented it's become. Right now I have humfurie.org and humphrey.humfurie.org running completely separate backends, and honestly, it looks messy.
The story: I started with a Laravel monolith (Inertia + React on top), which was great for getting something live quickly. Then I built humfurie.org as a Next.js project with a different backend written in a language I'm still gaining confidence in. Both frontends are React, which is good for consistency, but they're powered by completely different stacks. The Laravel side is tightly coupled as one bundle, which means I can't easily extract just the frontend layer.
So here's what I'm thinking: what if I stop pretending they're separate experiences and consolidate under one domain? Route everything through humfurie.org, then use humfurie.org/humphrey to serve the Laravel portfolio section. Everything under one roof.
Why this appeals to me
One domain feels cleaner from a brand perspective. It says "this is all me" rather than "these are scattered projects." It also simplifies the mental model for someone visiting: they see my main work (humfurie.org), then a dedicated section showcasing my Laravel backend skills. As someone who built their career on Laravel, that seems worth highlighting explicitly.
Plus, I already have Traefik running, so reverse proxying isn't the hard part. The question is whether the complexity is actually worth it.
But here's what makes me hesitant
The technical piece that's making me uncertain is routing. Traefik can absolutely route requests to different backends based on path. But does the application layer need to know about that routing? If Laravel is serving assets (CSS, JS), those paths are probably hardcoded relative to root. Suddenly putting it under /humphrey might break everything. The React frontend built with Next.js has its own client-side routing too, which assumes it owns the domain's routing logic.
Then there's the question of authentication and state. Are these apps sharing sessions, or are they isolated? If I route /humphrey/* to a completely separate Laravel instance, do they feel like one coherent experience, or like two apps awkwardly shoved together?
The bigger architectural question
I'm also wondering if this is actually the right call. Multiple domains are more SEO fragmented, sure, but they also signal that these are distinct projects. Consolidating under one domain could make the portfolio feel more cohesive, or it could just make it confusing: "wait, why is this Laravel admin panel nested under humfurie.org?"
On the other hand, a unified domain is what real SaaS platforms do. If I can pull this off smoothly, it shows I understand how to architect domain-level routing without creating technical debt.
The experiment angle
I'm genuinely not sure if this is worth doing, but it's fun to explore. What would I actually learn? How to handle prefix-based app routing without breaking client-side navigation. How to make two completely different backends feel like part of one system. Whether the effort of consolidation is worth the cleaner appearance.
The real question underneath all this is whether my portfolio should tell one story or many. One domain says "I built this cohesive thing." Multiple domains say "I can build multiple things independently." Both are true.
I'm leaning toward trying it, mostly because I want to see if it's possible without making both apps miserable to maintain. But I'd rather think through the trade-offs first.