A portfolio usually has a straightforward job: introduce the person, present selected work, explain relevant skills, and provide a way to get in touch.
PouyaOS started from a different design question.
What if the portfolio itself could become part of the work?
I did not want to place the same biography, project cards, skills, music, articles, and contact information inside a more decorative layout and call it experimental. I wanted the interface to demonstrate the same kind of systems thinking, front-end work, creative direction, and multidisciplinary structure that the portfolio was supposed to represent.
That decision eventually became PouyaOS: a web-based portfolio built around the interaction language of an operating system.
But the desktop interface is only the visible part of it.
Designing an environment instead of a sequence of pages
Traditional portfolio websites are usually linear.
You scroll from an introduction to a biography, then through projects, skills, perhaps some writing, and finally a contact section.
That structure is effective. It is also extremely familiar.
My work does not sit comfortably inside one category. I work across digital systems, front-end development, experience design, publishing, music, and creative production. I wanted the structure of the portfolio to acknowledge that complexity rather than compress everything into one long page.
An operating-system metaphor gave me a different way to think about the information.
Projects could exist as objects that users open and explore. Different forms of content could have different environments. Navigation could feel closer to interacting with software than browsing a conventional portfolio.
The important distinction, though, was that the operating-system idea could not stop at visual references.
Windows, applications, files, navigation, and system states are immediately recognizable visual concepts. They can make a website look like an operating system very quickly.
That was not enough for PouyaOS.
The metaphor needed to affect the structure and behavior of the portfolio, not merely its styling.
The interface had to carry some of the proof
One of the reasons I chose a technically demanding format was that I did not want the site to simply tell visitors that I could build complex interfaces.
I wanted part of that evidence to exist in the experience itself.
PouyaOS uses React and TypeScript, but the framework names are not what make the project interesting to me. What matters is what the interface asks those technologies to coordinate.
The experience has applications and application state. The desktop needs window-based behavior. Different types of information need to appear consistently across multiple parts of the system. Navigation has to remain understandable inside an unconventional interface. Desktop and mobile need different interaction patterns without becoming two unrelated portfolios.
The design challenge was therefore not:
How many operating-system features can I simulate inside a browser?
It was:
Which parts of the operating-system model actually improve the way someone can explore my work?
That distinction influenced almost every design decision that followed.
The desktop is a design language, not a costume
On larger screens, PouyaOS uses the interaction language of a desktop operating system.
That gives the interface a vocabulary that most users already understand: applications can be opened, information can occupy different windows or states, and the environment can be explored non-linearly.
The advantage is not only visual familiarity.
A desktop metaphor makes it possible to express relationships spatially.
A project does not have to behave exactly like a biography. Music does not need to be reduced to another project card. Media can have a different role from written content. Different pieces of the portfolio can remain part of one environment while still having different interaction patterns.
This is where I think many OS-inspired interfaces can become superficial.
If every icon ultimately opens another conventional content panel, the operating-system layer may only be decoration around the same underlying website.
I wanted PouyaOS to use the metaphor more deliberately.
The question became less about recreating a real operating system and more about deciding which parts of that model belonged in a portfolio.
A portfolio is still a communication product.
It should not simulate complexity simply because a real operating system is complex.
Mobile needed a different answer
One of the decisions I care most about in PouyaOS is something that becomes obvious only when you move away from desktop.
I did not want the mobile version to be a compressed version of the desktop interface.
Overlapping windows and pointer-driven interactions make sense when there is enough screen space and a mouse or trackpad. On a phone, the physical context is completely different.
Trying to preserve the desktop metaphor literally would have meant shrinking the visual idea while weakening the interaction.
Instead, I treated mobile as another operating environment.
The desktop experience uses a desktop-oriented model. The mobile version uses a touch-first, Android-inspired application model where the interaction is better suited to a phone.
The important part is that these are not two separate portfolios.
They are two expressions of the same system.
That led to one of the principles that shaped the project:
same information, different interaction model.
For me, this became a more useful definition of responsive design than simply making the same components rearrange themselves at different breakpoints.
The identity remains consistent.
The content remains consistent.
The behavior is allowed to change.
The visible interface was only one layer
As the project grew, I ran into a problem that had little to do with draggable windows or visual design.
The same information needed to exist in many places.
A project title might appear inside the operating-system interface, on a public project page, in metadata, in structured data, and in discovery systems.
A biography might appear inside an application but also need a stable public URL.
Music can exist as part of the interactive experience while still needing its own public record.
If every surface owns a separate copy of that information, the portfolio becomes difficult to maintain very quickly.
So the content model became part of the architecture.
Conceptually, the system looks more like this:
Shared Content
│
┌─────────────┼─────────────┐
│ │ │
Desktop OS Mobile OS Public Pages
│ │ │
└─────────────┼─────────────┘
│
Metadata / Structured Data
│
Search & Discovery
The interface is therefore a presentation of the information rather than the only place where that information exists.
That difference matters more than it may appear.
It means PouyaOS can remain visually experimental without forcing every other system to understand the portfolio through application state.
The portfolio also needed to exist outside the OS
An interactive application can be understandable to the person using it while still being a weak public reference.
A visitor may know that clicking an application opens a project.
Someone arriving from a search engine, a shared link, an article, or a media reference needs something more stable.
That is why important information in PouyaOS also has conventional public destinations.
The interactive experience and the public web layer have different jobs.
The OS answers:
What does it feel like to explore this portfolio?
The public page answers:
What exactly is this project, person, article, or release, and where is its stable URL?
PouyaOS uses canonical pages, semantic content, metadata, structured data, internal links, and sitemap outputs so that important information does not exist only behind an interaction.
None of that guarantees a search ranking.
That is not the point.
The goal is to preserve clarity while keeping the experimental interface intact.
For me, this became one of the most important design tensions in the whole system:
exploration and reference need to coexist.
Publishing is part of the product
Another part of PouyaOS that is mostly invisible from a screenshot is the publishing layer.
A personal site is rarely finished when it launches.
Projects change. Articles are added. Music releases appear. Images are replaced. Biography language evolves. Metadata needs updates.
That becomes especially important when the same information can appear across multiple surfaces.
I did not want maintaining the portfolio to depend on remembering every place where a fact had been copied.
The publishing model was therefore designed around structured records that could be reused by the experiences depending on them.
That changes the role of the portfolio.
It stops being only a launch artifact and becomes something that has to remain coherent while the person behind it keeps producing new work.
This mattered particularly for PouyaOS because the system was designed to represent multiple disciplines rather than one static set of development projects.
The hardest part was keeping the ideas from fighting each other
There was no single feature that made PouyaOS difficult.
The difficult part was making several different requirements coexist.
The interface needed personality without becoming confusing.
The operating-system metaphor needed enough depth to matter without forcing every piece of content to pretend it was part of a real computer.
Desktop and mobile needed to feel related without behaving identically.
The publishing model needed structure without making the creative interface rigid.
Important information needed stable public pages without turning the entire experience back into a conventional portfolio.
And the technical complexity needed to demonstrate something meaningful rather than exist for its own sake.
Those requirements pull the project in different directions.
That is why I eventually started thinking about PouyaOS less as an interface project and more as a systems-design problem.
A visual feature can usually be solved locally.
A system has to survive the interaction between features.
Visual detail only works when it has a structural reason
I care a lot about the visual side of PouyaOS, but I did not want visual novelty to become the whole argument for the project.
A creative interface has to earn its complexity.
The desktop environment makes sense because the portfolio contains different kinds of work that benefit from an application-oriented structure.
The mobile interface changes because the interaction context changes.
The publishing architecture exists because the information needs to remain consistent.
The public reference layer exists because not every visitor enters through the interface.
The operating-system metaphor is useful only because those decisions connect.
Without that connection, the design would be an elaborate skin.
With it, the interface becomes an expression of the architecture underneath it.
That is the part of PouyaOS I find most interesting.
What I learned from building it
The biggest lesson was not that portfolios should look like operating systems.
I actually think the opposite.
If everyone started building OS-style portfolios, it would simply become another template.
What I took from the project is that the form of a portfolio should reveal something meaningful about the person behind it.
A minimal portfolio may be the right answer for one developer.
Another might need something editorial, cinematic, game-like, or data-driven.
For me, an interactive system made sense because I wanted the portfolio itself to demonstrate how I think about software, interfaces, content, creative systems, and digital identity.
PouyaOS became the answer to that particular problem.
It is not just a place where I list the work.
It is part of the work.
Explore PouyaOS
Open the PouyaOS project
If you are interested in the deeper reasoning behind the content model, publishing architecture, search layer, and identity system, I have also written a longer breakdown on my site:
Portfolio as an Operating System: How I Built PouyaOS as an Interactive Web System
Editorial disclosure: I used AI-assisted editorial support while developing this article. The project decisions, experience described here, factual details, and final publication are reviewed and approved by me.
