How I built my portfolio

When I started building this portfolio, I had one main rule: keep it simple enough to maintain, but detailed enough to feel like it was made by a real person and not dropped from a template library. I wanted the page to look clean at first glance, then reveal more care in the small things like spacing, dashed borders, typography rhythm, and hover states.

Choosing the stack

I used Next.js because it keeps routing and rendering straightforward, and it lets me keep the whole portfolio inside a small codebase. That matters for a personal site. I don't want to spend more time maintaining the website than improving the actual work shown on it.

For styling, Tailwind CSS was the obvious choice. A portfolio has a lot of small visual decisions: rounded corners, muted text, compact metadata, hover polish, and responsive spacing. Utility classes make that iteration faster than writing separate CSS for every small change.

Designing for clarity

The design direction was intentionally narrow. I kept the background black, used soft gray text, and relied on dashed dividers and glassy cards instead of introducing too many colors. This created a system where the content becomes the focus, while the interface still feels crafted.

The important part was hierarchy. The hero should introduce me in a few seconds, the skill rows should show technical breadth quickly, and the cards underneath should make scanning easy. A lot of frontend work is not about adding more components. It is about removing visual confusion.

Good portfolio design is less about decoration and more about making your work easy to trust.

Adding motion carefully

I wanted the site to feel alive, but not noisy. That is why motion is used in a limited way: hovering skill pills, card transitions, and a moving star background. These details help the page feel active without distracting from the information.

Small motion decisions matter. If everything animates, nothing feels important. If only a few things react, the page feels more refined. That balance is what I aimed for throughout the build.

What I'd improve next

The next step is turning more static sections into real data-driven content. Projects should point to live demos or repositories, certifications can carry stronger descriptions, and the blog can grow into a place where I document engineering decisions instead of only showcasing finished work.