Crafnia

Notes

Notes

Field notes from a one-person software workshop

This is a running set of notes about how the apps on this domain actually get built, written by the person who builds them. There is no editorial team smoothing these out and no marketing pass turning them into pitches — each one is a specific decision, a specific mistake, or a specific fix, described the way it actually happened, including the parts that did not work the first time.

The subjects are ordinary by design: how a change gets from a local file to a public URL, why a particular framework got replaced with another one, what a wrong assumption about DNS or HTTP caching cost in real hours, and how a naming search that seemed simple turned out not to be. None of it is theoretical — every note here traces back to something that happened on one of the live apps linked throughout this site, and every number, date or detail in them is something that was actually measured or actually occurred, not a rounded-off estimate written to sound tidy.

The point of writing these down in public is not really about explaining Crafnia to anyone in particular. It is that most of these lessons are generic enough to apply to any small team shipping static sites on shared infrastructure, and the failure modes described here — a caching rule that looks right and is not, a DNS check that lies, a rendering choice that quietly breaks how a page gets read by anything other than a browser — are common enough that writing them down once is more useful than re-learning them app by app.

  • How a one-person software workshop ships

    Web first, mobile only if it earns it; static files and no backend where possible; every change goes through a preview link before it reaches production.

  • Choosing the name Crafnia

    craft.com was taken, most of a hundred backup names were too, and a domain that looked free under plain DNS turned out not to be — why RDAP is the check that actually tells the truth.

  • One domain, many apps

    How each app gets its own subdomain, why the Firebase site id is not always the product name, and how to tell a DNS record that has not propagated from one that was never saved.

  • Caching lessons from static sites

    A Firebase Hosting header rule that silently skipped the home page, and a stylesheet with no content hash that kept returning visitors stuck on an old design.

  • Why BlockClock's web version moved from Flutter to React

    Flutter's web canvas renders to a largely empty DOM, which is workable for a phone screen but a problem for search and ad crawlers — why the clock's web build was rebuilt in React instead.

  • Building AltClock as BlockClock's twin

    What it takes to reuse a working app's architecture for a second, related one without duplicating the parts that should stay shared.

  • FitCalc: calculators written like a coach's notebook

    Building fitness calculators as static HTML with zero dependencies, and designing the results to read like a written plan rather than a bare number.

  • Rebuilding Mystery Agents' pass-and-play mode

    Getting a local, phone-passing party game mode working end to end again, and what shipping it revealed about what "done" actually means for a game.