Building HusseinAkl.com as a Living Archive, Not a Portfolio

A portfolio is designed to exclude

Traditional portfolios are selective by design. They show the strongest work, remove the messy context and create a controlled narrative.

That is valuable when the only goal is to win work.

My problem was different. I wanted the website to represent a growing body of work across design, marketing, products, businesses and writing. A static selection started to feel like a snapshot of a moving system.

So I stopped thinking of the site as a portfolio and started thinking of it as an archive.

The archive needs structure

An archive cannot simply be a larger grid.

If everything is displayed in one stream, quantity becomes noise. The information needs different containers based on what it is.

That led to separate areas:

• Work for completed creative and professional projects
• Build for products and tools
• Worlds for larger brands and ongoing ventures
• Journal for developed writing
• Other resource areas for ideas, books and useful material

The categories are not just navigation. They describe different relationships to the work.

Relationships matter more than folders

The most important part of the system is not where a record lives. It is what it can connect to.

A Journal article can discuss a Build. A Build can belong to a World. A Work case can connect to the studio behind it. A book note can influence an article.

That is closer to how I actually think.

I rarely experience work as isolated files. One project changes how I approach the next. A client problem creates an idea for a tool. A product build produces a lesson worth writing about.

The website should preserve those connections.

The backend changed the frontend

Once the content model became relational, the public site could become simpler.

The frontend no longer needs to explain the whole ecosystem in every section. Each record can carry its own context and link outward when useful.

That allows the homepage to stay concise while the deeper archive grows over time.

It also changes maintenance. Adding a new article or product should not require redesigning a page. The system should be able to absorb new records without becoming visually unstable.

Why I wanted an authoring layer

I also knew that a structured archive would fail if publishing remained difficult.

That is why the backend matters even though most visitors will never see it.

I wanted a place where I could add media, edit relationships, manage metadata, schedule content and eventually maintain the site as an ongoing practice rather than a one-time development project.

The website only becomes a living archive if updating it is easier than ignoring it.

The danger of overbuilding

There is an obvious risk in building infrastructure for yourself: the system can become the project.

I have had to keep reminding myself that the archive exists to support the work, not replace it.

That means accepting imperfect automation, importing content in batches when speed matters, and postponing workflows that are elegant but not necessary for launch.

The right system is not the one with the most features. It is the one that makes publishing sustainable.

What a living archive means to me

A living archive is not a complete record of everything I have ever done.

It is a curated system that can grow without losing context.

Older work can be added when it becomes relevant. New products can appear while they are still evolving. Articles can document decisions before the final outcome is obvious.

That creates something a portfolio cannot easily provide: continuity.

The site becomes less about proving that I have done good work and more about showing how the work develops over time.