For a long time, I thought in websites. A website was the natural unit of work. It had a domain, a purpose and an audience. It was something bounded and understandable, a place where ideas could live and where projects could take shape. That way of working made sense because it imposed clarity. Each site had its own identity, its own structure and its own set of expectations. But over time, as the number of projects increased and their relationships became more complex, I started to notice that the website itself was rarely the most important part of what I was building.
What looked like separate websites on the surface were often expressions of deeper systems underneath. The site was only the visible layer. The real work was in the structure that connected content, datasets, documentation, repositories and decisions over time. Once I recognized that pattern, the way I approached building began to change. I stopped asking what website a project needed and started asking what system it belonged to, or what system it required to exist at all.
Websites Are Surfaces, Not Structures
A website is often treated as the final form of a project. It is where users arrive, where content is published and where identity becomes visible. But in practice, the website is usually just an interface. It does not fully represent the work behind it. A research initiative may span repositories, datasets, specifications and publications. A documentation project may involve schemas, versioning and governance models that are far more important than the pages where the documentation appears. Even a simple newsletter increasingly exists as part of a larger structure involving archives, metadata, references and cross-platform distribution.
This became more apparent the longer I worked across different domains. The visible properties looked distinct but the underlying mechanics often repeated. The same questions kept emerging. How should knowledge be structured? How should it be maintained? How should it be versioned? How should it connect to future work? These are not questions about websites. They are questions about systems.
That distinction matters because websites encourage thinking in containers, while systems encourage thinking in relationships. A container has boundaries. A system has dependencies, flows, and continuity. The shift from one to the other changes not only how projects are organized, but how they evolve.
Patterns Matter More Than Platforms
As I expanded into more areas, I started seeing recurring patterns across projects that had little obvious connection. Whether the subject was open standards, AI infrastructure, autonomous systems, or public datasets, the same structural concerns kept surfacing. Documentation needed to be clear enough to support future contributors. Data needed provenance so that its origin and transformations remained understandable. Publications needed context so they could connect back to the ideas or evidence that shaped them. Tools needed boundaries so their role inside a larger ecosystem remained legible.
At first, these seemed like isolated implementation concerns. Over time, they revealed themselves as part of a broader pattern. What I was really building was not a collection of separate websites but an interconnected body of systems, each reinforcing the others.
This changed my sense of scale. Instead of viewing a project as a standalone output, I started viewing it as an object in a wider architecture. A dataset could inform an article. That article could influence a specification. That specification could shape a tool. That tool could produce new data. The relationships between these parts often mattered more than any single artifact.
That way of thinking created more coherence across my work. It also made it easier to understand what belonged where and why.
Infrastructure Became the Real Discipline
At some point, I realized most of my important decisions had less to do with design and more to do with infrastructure. Not infrastructure in the narrow technical sense but structural infrastructure. This includes naming systems, taxonomies, schemas, documentation conventions and repository boundaries. These decisions rarely attract attention because they are not immediately visible but they determine whether a project remains understandable over time.
A poorly structured taxonomy creates confusion as content grows. A weak schema makes data harder to reuse. An inconsistent repository structure increases maintenance costs and makes collaboration more difficult. These issues are rarely obvious at the beginning, but they compound.
The opposite is also true. Good infrastructure creates leverage. A stable structure reduces friction. A clear naming convention makes future work easier to organize. A versioned documentation model makes change easier to manage. These are the kinds of decisions that improve not only the current state of a project but its future states as well.
That future orientation is what pushed me further away from website-first thinking. A website can be redesigned. Infrastructure decisions tend to persist.
A Portfolio is an Ecosystem, Not a Collection
This shift also changed how I think about my broader body of work. It became less useful to see each domain or project as a separate entity. Instead, I began to see them as nodes inside a larger ecosystem of research, tools, publications and datasets. Some projects exist to publish ideas. Others exist to formalize standards. Others exist to collect or structure information. Their purposes differ but they share common infrastructure and often inform one another.
This perspective reduced the pressure to make every project self-contained. Not every site needs to explain everything. Not every repository needs to stand alone. Some projects make more sense as parts of larger structures, where their value comes from how they connect rather than how they present themselves in isolation.
That has become one of the more useful mental shifts in my work. It encourages designing for interdependence rather than independence. It also reflects how knowledge actually develops, through accumulation, reference, revision, and recombination.
Continuity Became More Important Than Launch
The website model often encourages launch-oriented thinking. There is a clear beginning, a public release and then a maintenance phase. Systems thinking stretches the timeline. It introduces a longer view where continuity becomes more important than completion.
That changes the questions worth asking. Instead of asking whether something is ready to publish, I am more likely to ask whether its structure will remain useful in five years. Instead of asking whether a project is complete, I ask whether it can evolve without losing coherence. Instead of focusing on how something appears today, I think more about whether it can still be understood later.
This does not mean every project needs to be permanent. Temporary work still has value. But for anything intended to accumulate knowledge or support future work, continuity has become the more useful design principle.
It slows decisions down, but often improves them.
What Remains
I still build websites and I expect I always will. They remain useful interfaces and important access points. But I no longer treat them as the center of the work. More often, they are the visible edge of something larger, a way into a system rather than the system itself.
That distinction has changed how I organize projects, how I document them and how I think about their future. It has made me more attentive to structure, more interested in relationships and more willing to invest in infrastructure that may never be visible to anyone except the people who maintain it.
Over time, I stopped thinking in websites because websites began to feel too narrow for the kind of work I wanted to sustain. Systems offered a better frame because they could hold complexity without losing coherence. They could grow without fragmenting. They could connect work across time rather than freezing it at the point of publication.
For long-term work, that has proven to be the more durable model.
