The Site Should Be a Map, Not a Mask

I was looking at the personal site work from this week and the useful detail was not a new animation, a new color system, or a clever landing page trick. It was a boundary.

The homepage stayed broad.

That sounds like a small product decision, but it is the kind of decision that keeps a personal site honest. There was a very obvious temptation available: take the current public engineering work, turn the header into a sharper professional pitch, and make the whole site read like an execution-infrastructure portfolio. That would have been tidy. It also would have been wrong.

A personal site is not the same thing as a sales page. It can contain professional proof, but it should not flatten the person into the latest professional angle. The current work around justynclark.com made that distinction concrete. The project surface got updated with public tools. New direct pages were added for worlds, currently, studio, made, and field notes. The site gained more ways to expose the shape of the work without turning the front door into a narrow funnel.

That is the part I keep coming back to: the public surface is allowed to become more complete without becoming more reductive.

Most web work pushes in the opposite direction. The standard advice is to pick a lane, sharpen the headline, reduce ambiguity, and make the visitor understand one conversion path as fast as possible. That can be useful for a product page. It can be poisonous for a person who is building across multiple systems at once.

When the work spans software, music, writing, media, tools, operations, and a growing network of public projects, the site has a different job. It should not try to collapse the work into one sentence. It should help a visitor navigate the shape of the work without lying about its range.

That requires a different architecture.

A landing page tries to persuade. An operator surface tries to orient. It gives the reader a map: what exists, what is active, where the public artifacts live, which pieces are personal, which pieces are professional, which things are finished enough to inspect, and which things are part of an ongoing practice.

This week, that showed up in two related pieces of work.

The first was the direct personal pages. The site gained routes for worlds, currently, studio, made, and field notes. Those are not all the same kind of page. Worlds is a broad identity map. Currently is a living snapshot. Studio is closer to a workspace description. Made is an archive of things. Field notes is a lightweight writing surface. None of those pages needs to carry the whole identity by itself. Together they make the site more navigable.

The second was the Projects refresh. The project route gained public tooling references: loopexec, chat-notebook, yt-transcript, tmux-mission-control, Boardroom links, and the npm profile. That matters because projects are not just a list of names. A project page is evidence. It should point to real surfaces a reader can inspect: documentation, repositories, packages, and working sites. A reader should feel the difference immediately: not just names on a page, but doors that open.

The combination is more interesting than either change alone. One part protects the personal site from becoming a narrow career wrapper. The other part makes the engineering surface more concrete. That is the balance I want: broad identity, specific proof.

The same principle applies to the JCN side of the network. Public infrastructure should be legible as a system, not as a pile of unrelated links. The map gets easier to trust when the important surfaces are directly reachable:

• SMALL Protocol has its own docs surface.
• loopexec has its own docs site.
• Musketeer has its own public surface.
• JustBeatz has product and API surfaces.
• justynclark.com and justynclarknetwork.com sit above those systems as maps, not replacements.

That is a subtle but important distinction. A map does not need to be the territory. It needs to route attention correctly.

For an operator, this matters because the public internet is not just marketing. It is part of the working system. A docs site reduces explanation cost. A project page establishes public proof. A field-notes surface creates a place for observations that are too small for a canonical essay but too useful to disappear into chat. A personal worlds page gives the work enough context that the reader does not mistake one active lane for the whole person.

The old portfolio model struggles with this. It assumes a person has a set of polished case studies and a stable professional label. That is too static for systems work. The work changes shape as tools become packages, internal patterns become public protocols, private experiments become product surfaces, and operating lessons become writing.

A better model is closer to a public filesystem.

There is a root. There are directories. Some areas are polished. Some are living. Some are personal. Some are professional. Some contain source artifacts. Some contain notes. A visitor should be able to move through it without being forced into a fake linear story.

That does not mean the surface should be chaotic. Filesystems still need names, hierarchy, permissions, and conventions. A public site needs the same discipline. It should make clear what is current, what is archived, what is public proof, what is a personal note, what is a company field note, and what belongs somewhere else entirely.

The hardest part is deciding what not to centralize.

It would be easy to make justynclark.com carry every professional message. It would also be easy to make justynclarknetwork.com absorb every system and turn the network into an abstract brand. Both moves would blur useful boundaries. The personal site should preserve the full range of the person. The network site should explain the studio and systems. Individual project sites should carry project-specific documentation. Public packages should point to actual installable or inspectable artifacts.

Good surface design lets each layer do its job.

This is one reason I like direct pages. They let a site grow without forcing everything into the main navigation. Not every useful page needs to become a nav item. Some pages are meant to be sent directly, discovered from a relevant context, or linked from a specific artifact. That makes the site feel less like a brochure and more like a working environment.

There is a maintenance cost, of course. More surfaces mean more drift risk. If the project list says a tool exists, the link should work. If a public route is deployed, the route should keep returning 200. If a site claims a project is live, the docs should not contradict it. The more the public surface becomes part of the operating system, the more documentation drift becomes a real bug.

That is where receipts and verification become part of the writing process. The recent site work was not just described. Routes were checked. Builds ran. Production links were smoked. The public endpoint checks included smallprotocol.dev, loopexec.dev, musketeer.dev, justbeatzmusic.com, justynclark.com, and justynclarknetwork.com. That does not make the surface perfect, but it changes the posture. The site is not an imagined brand map. It is tied to running artifacts a reader can visit.

I think this is where personal sites become interesting again.

For a long time, the personal site was either a resume, a blog, or a design object. Those are still valid shapes, but they are not enough for people building operational systems. The site can become a public control surface for attention. It can say: here is the person, here are the systems, here are the tools, here is the writing, here is what is active, here is what you can inspect.

That is a more useful ambition than polish by itself.

The point is not to make every private thing public. Quite the opposite. A good public surface protects private context by giving enough public structure that the work can be understood without exposing internal queues, client details, credentials, finances, or diary-like operations. The public map should be accurate, but it should not be a leak.

That is the discipline: expose shape, not internals.

When a site does that well, it becomes easier to trust. The reader does not have to accept a vague claim about building tools. They can click through to project pages, docs, packages, and public routes. They can also see that the work belongs to a person with more than one lane, not a content machine pretending every week has one perfect thesis.

That is the system I want the public surface to become: broad enough to be honest, specific enough to be useful, and structured enough to survive growth.

A personal site should not flatten a life into a tagline. A network site should not blur products into fog. A project site should not pretend to be the whole company. Each surface should carry the right level of context.

The web gets better when sites behave less like billboards and more like maps.