This is the version of my portfolio where I finally stopped treating it like a static site and started treating it like a small system. The main shift was simple but important. Instead of rebuilding or redeploying every time I wanted to add something, I wanted the portfolio itself to be capable of growing without friction. That idea became the base for everything.
Scalability has been something I’ve been increasingly focused on this year, not in the “big distributed systems” sense, but in the practical sense of building things that don’t get harder to maintain every time they evolve. This portfolio is a direct reflection of that mindset.
Content as a system, not static pages
One of the biggest changes compared to the previous version was moving away from hardcoded content. Projects and blog posts are now stored in a database instead of being written directly into the codebase. That means I can add, update, or remove content without touching the deployment pipeline at all. No rebuilds just to add a new project or publish a post.
For me, this was not about overengineering a portfolio. It was about aligning it with how I actually think about systems now. If content changes often, it should not require code changes. That separation felt obvious once I started applying it consistently.
It also made the portfolio feel more like a real product instead of a personal page. There is a backend layer that handles data, and a frontend layer that focuses purely on rendering and experience. That separation alone made the system cleaner and easier to evolve.
Tech stack and structure
The stack stayed close to what I already use in most of my work. Next.js remains the foundation for the frontend and routing, while TypeScript keeps everything consistent and predictable as the codebase grows. Tailwind CSS is still used for styling, but in a much more controlled way compared to earlier versions. Less experimentation, more consistency.
On the deployment side, Vercel continues to be the obvious choice. The workflow from commit to production is still one of the most efficient parts of the setup, and it fits well with the idea of iterating frequently without friction.
The more interesting part is the backend structure. Instead of treating the portfolio as a purely frontend project, I introduced a proper data layer to manage content. Projects, blog posts, and related metadata are all handled through a database, which gives me full control over how the site evolves without redeploying for every small change.
Design direction shift
Design-wise, this version is very different from the 2025 one. The previous portfolio leaned heavily into a darker, more “edgy” aesthetic. It was more about personality expression than usability. For this version, I deliberately moved away from that.
The focus became something more balanced and much easier to consume. A more gentle, modern layout that feels familiar rather than aggressive. The goal was not to impress visually, but to make the content easy to understand for anyone who lands on it, whether that is a recruiter, a developer, or someone just browsing.
There is still a bit of personality in the design, but it is controlled. The intention was to remove friction, not create attention through visuals. If anything, the design now tries to stay out of the way and let the content speak first.
What changed in mindset
The biggest shift is not really technical, it is how I think about personal projects. Earlier versions of my portfolio were about building something complete and then moving on. This version is closer to a system that is expected to evolve continuously. Adding a new project or writing a blog post is not a “new version of the site” anymore, it is just updating data.
That change also reflects how I’ve been thinking about scalability in general this year. Not in abstract terms, but in practical decisions like reducing friction, avoiding unnecessary rebuilds, and designing systems that don’t slow down as they grow.
What this portfolio represents
At this point, this portfolio is less about showing what I can build and more about how I think about building systems. The combination of a structured frontend, a proper data layer, and a design that prioritizes usability over visual impact reflects the direction I want to keep moving in.
It is still evolving, and that is intentional. The goal is not to freeze it into a perfect version, but to keep it flexible enough that adding new work does not feel like a rebuild every time.
And yes, it is also designed to be something that recruiters can actually go through without needing to decode it.