From GitHub and Vercel to an Interactive Portfolio Site

One of the most useful parts of this project was that it forced me to get practical with the workflow around publishing code, not just writing it. I wanted a real portfolio site online under my own domain, which meant I needed to get comfortable with GitHub as the source of truth and Vercel as the place where the site actually shipped.

That sounds basic on paper, but there is a meaningful difference between understanding those tools conceptually and using them on a real project that you intend to keep improving. The first hurdle was simply getting a working repository, understanding what needed to be committed, and building enough confidence in the loop of edit, push, deploy, and verify.

Vercel was especially helpful because it shortened the path from local work to a live result. Once the project was connected and the domain story started to make sense, the site stopped feeling hypothetical. It became something I could iterate on quickly and see in production without a lot of deployment overhead.

The early version of the site was intentionally straightforward. I needed a clear, readable portfolio that covered the basics well: who I am, what kind of work I do, the environments I have worked in, the projects I am proud of, and how someone could contact me.

That version mattered because it solved the immediate problem. It gave me a public-facing site that was professional, simple to browse, and much more useful than leaving my work history scattered across resumes, notes, and half-finished ideas. It also gave me a stable baseline to compare future changes against.

I think that step is easy to undervalue. A lot of projects stall because the first version tries to be the final version. In this case, the plain portfolio was important because it made the site real before it made the site interesting.

Once the basics were live, the next question was whether the site actually felt personal. The clear version was useful, but it did not really reflect the way I wanted to present myself. I wanted something that still read professionally while also having more personality and a stronger point of view.

That led to the interactive concept. Instead of treating the homepage like a standard hero-and-cards layout, I started thinking about it as a small world organized around hobbies and interests that connect back to my professional story. The site could still carry serious information, but it did not have to do it in the most interchangeable way possible.

The important design constraint was that the playful part could not come at the expense of usability. I still needed a direct path for recruiters, mobile visitors, and anyone who just wanted the straightforward version. That is what eventually led to treating the interactive homepage and the portfolio route as two surfaces of the same product instead of forcing one page to do everything.

As the project became more ambitious, the underlying structure needed to improve too. What started as a simpler static-style portfolio evolved into a Next.js App Router application that could support the interactive homepage, a mobile-friendly portfolio page, and a blog without splitting the project into disconnected pieces.

That architectural shift was less about chasing a framework and more about maintainability. I wanted one app, one deployment target, shared metadata, reusable layout pieces, and a structure that would still make sense after the site grew beyond a single landing page.

The blog was part of that same evolution. Once the site was no longer just a resume surface, it made sense to create space for project write-ups, notes, and build logs. That changed the job of the site from “show who I am” to “show who I am and how I work.”

GitHub and Vercel helped because they reduced the friction around iteration. GitHub gave the project a clear home and a natural checkpoint for meaningful changes. Vercel made it easy to turn those changes into a live site quickly enough that experimentation stayed fun instead of feeling heavy.

• I could make incremental changes without treating deployment like a separate project.
• The live site stayed close to the current code instead of drifting from it.
• Route, content, and design improvements could all ship through the same workflow.
• The domain-level result felt polished even while the internals were still evolving.

That matters for a personal site more than people sometimes admit. A portfolio is easier to improve when the publishing process is calm. If every update feels brittle, you stop making updates. If the loop is simple, the site becomes something you can keep shaping over time.

The biggest lesson was that a personal site gets better when it is allowed to evolve in stages. The first useful version does not need to be the most expressive version. It just needs to exist, be clean, and give you something solid to improve from.

I also learned that the most satisfying projects are the ones where the technical structure and the identity of the project grow together. The interactive homepage is more distinctive because the underlying app is now organized well enough to support it. The cleaner portfolio route is better because it does not have to carry every idea by itself. The blog works because it lives inside the same foundation instead of being bolted on as an afterthought.

This project ended up being valuable for more than the final visuals. It taught me the practical path from local code to a live site, forced me to get more comfortable with GitHub and Vercel as real tools instead of abstract concepts, and gave me a project that could evolve from a plain portfolio into something much more personal. That progression is part of what makes the site meaningful to me now.