This site is intentionally opinionated.

I did not want another content system that ships a server stack, an admin runtime, a plugin sprawl, and a page that needs hydration just to render text. I wanted a blog that behaves like infrastructure notes should: direct, fast, and easy to reason about.

The baseline rule

The baseline rule is simple: reading should never depend on the most experimental part of the site.

That is why the homepage can carry a WebGL globe while article pages stay close to static HTML. The globe is an accent and a signal surface. The writing is the product.

Why keep the globe at all

Because it says something about the kind of site this wants to be.

I care about systems that are both useful and expressive. A visitor globe is not necessary, but it is a compact demonstration of several ideas working together:

  • static-first rendering
  • edge data ingestion
  • privacy-aware aggregation
  • a visual layer that feels alive without hijacking the whole page

The trade-off that matters

The hard problem is not drawing points on a sphere. The hard problem is coordinating state without accidentally building a surveillance feature or a fragile distributed race.

That is why the first production version will not chase perfect real-time semantics. It will prefer a short-lived snapshot model:

type VisitorPulse = {
  lat: number;
  lng: number;
  observedAt: string;
  accuracy: "coarse";
};

That small decision does a lot of work. It keeps the budget predictable, it softens consistency requirements, and it avoids treating a personal blog like an ad-tech dashboard.

What gets built next

The next meaningful milestone is not another visual effect. It is the publishing system itself:

  1. content collections
  2. article pages
  3. feeds and metadata
  4. a real visitor snapshot contract

Once those are stable, the live globe stops being a mock and becomes a restrained, explainable system.