My First Deployment

I was excited about this project — this is the first project I deployed to Github Pages! In this blog, I will walk through the hiccups I went through, what technologies I used, and things that you should probably keep in mind for first time website deployers.

Why I Started This Portfolio as a Beginner

As I mentioned in my previous blog, after exploring different career paths, I eventually landed on front-end web development. I was drawn to it because it allows me to bring designs to life and see immediate results from my work. Whether you're aiming for an office job or freelance gigs, having a portfolio is essential. That's why I decided to start building one early — even as a beginner — so I could start applying for work and track my progress as I grow.

This portfolio also happens to be one of the final projects required to earn the Responsive Web Design certification from freeCodeCamp, which gave me the push I needed to start.

Learning While Building

Overall, this project wasn't too difficult for me because I had already spent time learning HTML and CSS by building small projects through freeCodeCamp and getting help from ChatGPT. I also had a clear idea of how I wanted to structure the site from the beginning, which made the process smoother. I'll talk more about the tools I used in a later section.

That said, CSS Grid was new to me. I had just learned it while working toward the “Responsive Web Design” certification on freeCodeCamp. I also used it in one of the required projects. I'm still learning how to use it effectively, and I know it will take a long time to truly master. But applying it here gave me some real practice.

I also picked up a few lessons from the problems I ran into, which I'll cover in the next section.

Mistakes I Made (And What They Taught Me)

Even seasoned developers run into bugs or overlook simple things — and I experienced the same. But each mistake turned into a learning opportunity.

Let's dive right in!

The CTA Button Wouldn't Shift Down as Expected

Reason: In my original layout, both the .navbar and .hero-title were placed inside the <header> element. I had applied position: sticky; to the .navbar, but it didn't work properly — the layout made it unclear which container the sticky behavior was relative to, and the extra content inside <header> interfered with it.

Fix: I restructured the layout so that the .navbar became a <nav> inside the <header>, and moved the .hero-title into the <main> section. This separation allowed the position: sticky; on the header to work properly, since it was no longer being affected by the extra content within the same container.

The "About Me" Section Didn’t Look Right

Reason: I tried to style the paragraphs with text-align: justify; and text-indent to make it look like a novel. After seeing the result, I didn't like how it turned out.

Fix: I removed the text-indent property, kept the justified text, and added padding-bottom to create space between paragraphs instead.

Paragraphs Had Unwanted Space Between Words

Reason: When I checked the site on my mobile phone and on my brother's monitor, I noticed awkward spaces between words. This was due to text-align: justify;, which stretches words to fill the line width.

Fix: I changed letter-spacing from using px to em (for better responsiveness) and added word-wrap and hyphens to help control overflow and reduce gaps.

Unordered Lists Looked Cramped

Reason: The <ul> elements didn't have a defined line height, so by default the items looked too close together.

Fix: I added line-height to increase spacing between list items for better readability.

The Last .project-tile Card Appeared Shorter Than the Others

Reason: This was expected behavior from CSS Grid. Since the last card appeared in a new row without any other cards to match height with, it shrank to the minimum content height.

Fix: I first tried using min-height, but the real solution was setting grid-auto-rows: 1fr;. This made all cards within the grid maintain equal height regardless of how much content they had.

Hamburger Toggle Wasn’t Behaving as Expected on Mobile Devices

Reason: This was a specificity issue. I had updated the class names for the hamburger toggle, but my .navbar ul styles inside the @media query were overriding the display: none; rule I had for .nav-menu.

Fix: After a few failed attempts, I realized the issue was inconsistent class usage. I replaced all instances of .navbar ul with .nav-menu to make the class usage consistent and avoid conflicts.

If you're interested in seeing the steps I took or reviewing the code, you can find it here: GitHub Repo

Why I Chose This Design

For my portfolio, and most of the sites or apps I create, my focus is on simplicity and functionality. I want users to have the easiest possible experience. To support that, I prioritized accessibility over flashy design elements.

Color

The color palette I chose reflects my current mental space. I'm not in the best place mentally right now, and I wanted the design to reflect that — a sense of darkness, with a small hint of hope. That personal touch felt honest and helped give my portfolio more character.

Responsiveness

As mentioned earlier, I used responsive units like em, rem, and percentages for fonts, spacing, and layout. I also used @media queries to ensure the design worked across desktop, tablet, and mobile screen sizes. Some parts of the layout changed depending on screen width — for example, I don't use a navigation toggle on desktop or most tablet views.

One thing I overlooked was designing mobile-first. I went with a desktop-first approach out of habit. While it didn't break anything, I know that mobile-first is considered an industry best practice, especially since most users now browse primarily on their phones. I plan to keep that in mind for future projects.

Tools I Used

Here are the main tools and resources I used to build this portfolio:

I kept the stack minimal and beginner-friendly, since that's where I'm at right now. It helped me focus on learning good structure, layout, and styling fundamentals instead of overwhelming myself with too many tools.

What I Would Do Differently Next Time

There's not much I'd change about how I built this project, but a few things come to mind. First, I'd make sure to follow a mobile-first approach instead of starting with the desktop version. It's a good habit and aligns better with current industry standards.

I also want to be more organized during the build process — either by being more attentive or using a to-do list or task manager app to track what needs to be done.

For future projects, I'd like to try using Tailwind CSS or maybe a preprocessor like SASS. I haven't learned them yet or fully explored what they're used for, but I know they're part of the learning path for front-end developers. I'm looking forward to learning how they can help streamline styling and make code more efficient.

Final Thoughts

This project was more than just another item to check off my learning path — it was a real chance to put my skills to the test and see how far I've come. Even though I'm still a beginner, I learned a lot about how I work, what I need to improve, and where I want to go next as a developer.

There were challenges along the way, but overcoming them gave me more confidence in my abilities. I know there's still a long way to go, but that's part of the process. With every project, I'm learning to build cleaner code, better layouts, and more user-friendly experiences.

I look forward to revisiting this portfolio later with new skills — maybe rebuilding it using Tailwind or SASS — and continuing to grow, one step at a time.