My portfolio still worked. The codebase didn’t feel like mine anymore.

I built my portfolio in 2024, shipped it, and then mostly forgot about it.

The site kept working, analytics were showing some activity, so there was never any real pressure to come back to it. But after more than a year, both the content and the code were starting to feel outdated. My work had changed, my standards had changed, and the site no longer reflected either.

I originally opened the project just to update a few pages. That quickly turned into a much bigger refactor.

What had aged

Nothing was seriously broken. It was more annoying than broken.

Dependencies were outdated, responsibilities were mixed across folders, and some decisions no longer matched how I structure frontend projects today. The code was still understandable, but every small change took more effort than it should have.

That was the main issue: friction.

A portfolio should be one of the easiest projects to update. Mine had reached the point where I was putting off small changes because I did not feel like dealing with the codebase behind them.

Why Feature-Sliced Design

I decided to migrate the project to Feature-Sliced Design because that's what I've grown used to and I wanted clearer boundaries between different parts of the codebase.

I already use FSD in other projects, so the structure feels natural to me. More importantly, it gives me a predictable answer to a simple question: where should this code live?

I did not want to turn a small personal website into an enterprise application, though. I kept the structure intentionally light and only introduced layers where they actually made sense.

The hardest part was not moving files around. It was deciding which boundaries were real and which ones I was inventing just to make the folder structure look cleaner.

What I changed

I migrated the project gradually instead of rewriting everything from scratch.

I reorganized the existing code, updated dependencies, removed unused abstractions, simplified imports, and separated content-driven sections from interactive functionality. I also added versioning and tightened the dependabot configuration, so dependency updates arrive in smaller, reviewable batches instead of becoming another year-long backlog.

The site did not need a visual redesign, so most of the changes are invisible from the outside.

Internally, though, it is much easier to navigate. Adding content feels straightforward again, and I no longer need to reconstruct the entire project in my head before changing something small.

Key takeaways

I realized that still online and still maintained are two very different things.

Because the site kept working, I kept telling myself it was fine. Meanwhile, the content got stale, dependencies piled up, and every small change became more annoying than it needed to be.

A few small updates throughout the year would have been much easier than returning later and fixing everything at once. This time, I added some guardrails and processes to make sure I don't let it get out of hand again.

The site still looks mostly the same. It just feels like mine again.