Migrated my portfolio from plain HTML, Sass, and JavaScript into a modern Next.js application with TypeScript and Sanity CMS.
At some point, my portfolio stopped reflecting how I actually work as a developer.
The original version was built with plain HTML, Sass, and JavaScript. It did the job, but as the project grew, updating content became increasingly manual. Projects were stored in arrays of objects, layouts became harder to maintain, and making larger changes started feeling more annoying than it should.
So instead of patching things endlessly, I decided to rebuild it properly.
The rebuild started with migrating the project to Next.js and TypeScript.
This introduced a much more structured development workflow, better component organization, stronger type safety, and cleaner long-term maintainability.
What used to be a static portfolio gradually became a proper application.
Instead of hardcoded data and manually updating arrays of project objects, content became dynamic and easier to manage.
That shift completely changed how I approached the project.
One of the biggest improvements was integrating Sanity as a headless CMS.
Rather than storing project information directly inside the codebase, I moved everything into structured content schemas. Projects, tags, descriptions, technologies, and selected work entries could now be managed independently from the frontend itself.
This made the portfolio significantly easier to scale and maintain.
It also gave me experience working with schema design, content modeling, dynamic rendering, and handling CMS-driven applications in a real-world setup.
Turns out updating content is much nicer when you are not digging through arrays at 1 AM.
The rebuild also pushed me to rethink the frontend architecture itself.
I focused more on reusable components, cleaner project structure, responsive behavior, and improving the overall developer experience while working on the project.
Using TypeScript helped reduce mistakes and made component contracts much clearer, especially as the application became more dynamic.
I also spent more time refining UI interactions, animations, loading states, and overall polish, treating the portfolio less like a simple website and more like a real product.
Beyond the frontend itself, the migration introduced me to more modern workflows and tooling.
I worked with deployment pipelines, environment variables, CMS integration patterns, and production hosting using Vercel.
The project also gave me a better understanding of how modern React applications are structured using server rendering, routing systems, API integrations, and content-driven architecture.
Because it was my own project, I had the freedom to experiment, refactor, and improve things continuously without worrying about breaking a client website on a Tuesday afternoon.
Rebuilding my portfolio became much more than a visual redesign.
It was an opportunity to modernize both the technology stack and the way I approach frontend architecture, content management, and application structure.
The project helped bridge the gap between traditional frontend development and modern full-stack workflows, while also giving me a portfolio that better represents how I build applications today.