Intro
I started building my portfolio because I wanted something more useful than a static resume page. A resume is important, but it compresses too much context into short bullet points. It can say that I work with .NET, SQL, backend systems, and full-stack projects, but it does not show how I think, how I explain technical decisions, or how I connect learning with actual project work.
The goal was to create a proof-of-work hub. I wanted one place that connects my resume, GitHub, LinkedIn, project case studies, writing, services, and contact information. I did not want the site to look fancy for its own sake. I wanted it to help someone understand what I am building and what direction I am growing in.
Why I worked on this
I worked on this because I wanted recruiters and collaborators to see more than a list of technologies. My experience includes enterprise .NET work, SQL-heavy systems, jQuery, Kendo UI, and newer personal projects with .NET 8, React, Next.js, PostgreSQL, Docker, and cloud deployment. Without a portfolio, those things can look disconnected.
A portfolio gives me a way to explain the connection. It shows that I am using my professional backend experience as a base while actively building modern projects. It also gives me a place to write about the process, not only the final result.
What problem I was trying to solve
The problem was presentation and context. A project card can show a title and tech stack, but it does not explain why the project matters. A GitHub repository can show code, but it may not explain the problem, the tradeoffs, or what I learned.
I wanted the portfolio to solve that gap by giving each project a case study page. A good case study can explain:
- what the project is
- what problem it solves
- what I built or planned
- what technologies I used
- what was difficult
- what I would improve next
That context is more valuable than a random list of links.
How I approached it
I started with the structure. The homepage needed to communicate my direction quickly: backend-focused full-stack development, .NET, SQL, system design, and business applications. After that, the site needed deeper sections for projects, blogs, services, and contact.
I built it with Next.js, React, TypeScript, Tailwind CSS, Resend, and Vercel. Next.js gave me a clean routing model, TypeScript helped keep shared data structured, Tailwind made it easier to stay consistent visually, Resend handled the contact form, and Vercel gave me a simple deployment path.
I also made project and blog data shared instead of duplicating content across pages. That keeps the homepage, project listing, project detail pages, and blog pages from drifting apart.
What I learned technically
The biggest technical lesson was that even a portfolio benefits from architecture. It is easy to treat a personal site as a collection of pages, but once projects, blogs, and detail pages are added, the content model matters.
I also learned that design consistency matters more than visual effects. Reusable sections, cards, labels, tags, and buttons make the site feel more professional without making it noisy.
Another useful lesson was that writing is part of engineering presentation. If I cannot explain a project clearly, the project is harder for other people to evaluate.
Mistakes or confusing parts
At first, it was tempting to make the content sound like a resume. That made the site feel generic. The better direction was to write in a practical way: what I built, why I built it, what I learned, and what I would improve.
Another confusing part was deciding how much detail to include. Too little detail makes the site shallow. Too much detail can overwhelm visitors. I am still trying to balance skimmable pages with useful explanations.
What I would improve next
I want to keep improving the case studies with diagrams, screenshots, and more concrete technical decisions. I also want to keep the blog active as a learning timeline instead of treating it like a generic SEO section.
The portfolio should keep changing as my projects mature. That is the point of a proof-of-work hub: it should grow with the work.
Final takeaway
A developer portfolio should not only say what you know. It should show how you work. For me, the portfolio is a practical way to connect projects, writing, experience, and learning into one place that is easier for recruiters and collaborators to understand.