#What I Realized While Building My Portfolio: The Hardest Part Wasn't the Design
When I first started building my portfolio, I honestly thought, "As long as I can make it look good, that should be enough."
I focused entirely on the surface level: tweaking layouts, picking images, adjusting whitespace, and trying to nail that professional "vibe." In the beginning, that was all I cared about.
However, as I got deeper into the process, I realized that the real challenge wasn't the design itself. It was everything happening behind the scenes.
Organizing the structure, splitting components, deleting unused variables and legacy code, and maintaining consistency across the entire site—these tasks took far more time than actually "designing" the visuals.
Looking back, here is what I learned about the hardest parts of portfolio development.
#1. Visuals are easy to fix; a messy structure is a nightmare.
At first, I prioritized making the screen look right. I’d slap on a few classes, fiddle with margins, and hard-code logic on the fly. It worked—in the short term.
But this approach quickly became painful.
- Fixing one thing would break another.
- The blog list looked great, but the detail page felt completely disconnected.
- A tiny adjustment required me to re-examine every related component.
I learned the hard way that no matter how good the UI looks, if the underlying structure is a mess, every update becomes a chore. "Just making it work" is fine for a start, but it makes the final stretch incredibly exhausting.
#2. Componentization isn't just about "clean code."
I used to think componentization was just a way to make code look pretty. I was wrong. The real value is maintainability.
Take the blog section, for example. You have cards, article pages, tables of contents, and related posts. If all of this is crammed into one giant file or if the responsibilities are vague, you become afraid to touch the code because you don't know what might break.
When components have clear, single responsibilities, life gets easier. You know exactly where to go to fix a bug, and you're less likely to cause a chain reaction of errors. Even if you're the only one working on it, your "future self" will thank you—because code you wrote a few days ago can feel like a total stranger's work.
#3. Ghost code and unused variables are a mental drain.
During development, it’s tempting to leave old code or unused variables behind just to keep moving. I told myself, "I'll delete this later."
But these "ghosts" haunt you.
- Variables that lead nowhere.
- Functions that are remnants of a discarded design.
- Props that are passed but never used.
Every time you read through your code, you waste mental energy asking, "Do I still need this?" It kills your momentum and clouds your vision. I realized that a task isn't "done" when the feature works; it’s done when the redundant parts are purged.
#4. Matching the "vibe" across the site is harder than mimicking a single design.
It’s relatively easy to polish one specific section by looking at a reference. You adjust the font size, the border-radius, and the shadows until it looks right.
The real difficulty lies in systemic consistency. If the blog list looks premium but the contact page feels amateur, the whole site feels "off." Maintaining the same atmosphere, spacing rules, and tonal consistency across every single page is a massive undertaking. It’s a constant cycle of micro-adjustments. I learned that a great portfolio isn't just a collection of pretty pages; it’s a unified experience.
#The Biggest Takeaway: "Building" and "Organizing" are different skills.
This was my biggest epiphany. Writing code to display something on a screen is one thing. But "organizing" that code is a different beast entirely.
- Making the structure intuitive.
- Ensuring the project is easy to modify.
- Cleaning up the clutter.
- Maintaining visual harmony.
Doing these things is what actually makes a project "complete." Anyone can make a page appear, but the ability to keep it organized is where true skill shows.
#Summary
Before I started, I thought design would be my biggest hurdle. It wasn't. The real challenge was the invisible work: the architecture, the refactoring, and the consistency.
Designing the surface is fun, but without a solid foundation, you’ll eventually hit a wall. Building this portfolio taught me that "making it pretty" is only half the battle—the real work lies in making it sustainable. Moving forward, I want to write code that isn't just functional, but easy to live with.