I started trying to build my own portfolio in 2014, around the beginning of my university life.

Most of those attempts followed the same pattern.

I would begin with a simple idea, then decide the site needed a more impressive animation. That animation would lead to a different layout. The new layout would need more interactions, custom transitions, and another redesign.

Eventually, the project would become too large to finish.

The problem was not that I could not build the site. I had worked with Angular, React, and other frontend technologies. I knew enough to keep adding features, and that was part of the problem.

Every new technical possibility gave me another reason not to publish.

I was building for the wrong purpose

For a long time, I treated the "wow" factor as the most important part of the portfolio.

I wanted someone to open it and immediately be impressed, so I kept putting more effort into animations, interactions, and visual ideas before the site itself was complete.

The problem was not that a portfolio should avoid strong design. A polished and memorable experience still matters. The problem was the order in which I was building it.

I was prioritising the most visually exciting parts before the parts that created the most value: clearly explaining who I am, what I work on, what I have built, and how someone can learn more about me.

A visual effect should strengthen the finished site. It should not become the reason the site never gets finished.

I eventually realised that the first version needed to make the biggest impact with the smallest complete scope. Once that foundation existed, I could add the details that made it feel distinctive.

It needed to answer simpler questions:

  • Who am I?
  • What kind of work do I do?
  • What have I built?
  • Where can someone read more about my thinking?
  • How can someone contact me?

Once I looked at the portfolio this way, many of the features I had considered essential became optional.

The site still needed personality

Changing the goal did not mean creating a plain or careless website.

I still wanted the portfolio to feel polished and memorable. I care about how people experience the things I build, even when the product is mainly informational.

That is why the homepage still includes a fluid animation.

The animation creates an immediate impression, but it is no longer the foundation of the site. The important content does not depend on it. My name, work, navigation, and writing remain available without the effect.

This was a major change from my earlier attempts.

Previously, I designed the experience first and tried to fit the content around it. This time, I treated the content as the foundation and the animation as an enhancement.

The effect has a job, but it does not control the project.

I chose tools that helped me finish

I also became more careful about choosing technology based on the actual requirement.

The portfolio is mostly content. My experience, projects, biography, and articles only change when I update them. It does not need to behave like a large web application for every visitor.

I chose Astro because it made it straightforward to build static, content-focused pages. For the writing section, I started with MDX because it was the simplest way to begin publishing.

At that stage, simplicity mattered more than building a complete content system. I could write an article, keep it in the repository, and publish it with the rest of the site.

Later, I realised I did not want unfinished drafts stored anywhere the public site could accidentally expose them. That was when I moved the blog to Sanity.

The important part was that I did not start there. I first used the smallest system that helped me write. I changed the setup only after I had a clearer requirement.

I explain the static architecture, page structure, sitemap, metadata, and other visibility decisions in How to Build a Portfolio for Better Online Visibility.

I stopped waiting for the final version

One of the ideas that blocked me for years was that a portfolio needed to be complete before it could go online.

But a personal website is never really complete.

My experience will change. I will add new projects. I will publish new articles. The design will improve, and the technical foundation will evolve.

Trying to predict and build every future requirement only creates more reasons to delay the current version.

The portfolio I have now is not the final portfolio I will ever have. It is the first version that clearly represents where I am today.

That is enough reason to publish it.

Finishing changed how I see side projects

The portfolio was not the only project I treated this way.

I have abandoned other personal projects after expanding their scope far beyond the original idea. I often wanted the first release to include the kind of architecture and polish that should have come after real usage.

Each extra feature felt like an improvement, but together they made completion less likely.

Finishing this portfolio made that pattern harder to ignore.

There is a difference between caring about quality and refusing to release anything that is not perfect. Quality helps a project become useful. Perfectionism can prevent it from becoming real at all.

That subject deserves a separate article because it affected more than this website.

What finally worked

I did not finish the portfolio because I found the perfect framework or the perfect design.

I finished it because I changed the definition of success.

Success was no longer building the most impressive website I could imagine. It was building a clear, polished site that represented my work and could improve over time.

The animation still matters. The design still matters. The technical choices still matter.

But they serve the portfolio now. They no longer prevent it from existing.