01 · the starting point

A site that did not open on a phone.

She arrived with a previous build she liked the look of and could not use: no backend, and on a phone the hero name rendered at near-zero opacity while the navigation collided with itself. The first job was to measure it, not to guess at it.

Previous build, image lookup per piece108ms

Batched lookup, 300 pieces8ms

Full index of the archive5ms

02 · the studio

She runs it. From her phone.

An installable Studio, private to her, where the archive gets built the way she actually works: drop a batch of photos and get private drafts without being forced to file them, then write, arrange, and publish when she is ready.

1. 01Drop the photosA batch of images becomes a batch of private drafts in an Unfiled bucket. Uploading never forces a filing decision she has not made.
2. 02Write about the workQueues for needs-writing, drafts, and unfiled, with search across all of it and a caption per image.
3. 03Arrange the home page by handA control rail whose sliders write the CSS variables the live stylesheet reads. What she arranges is the site, with a separate arrangement for the phone.
4. 04PublishDrafts stay private by default. Publishing is her decision, per piece.

03 · privacy

Enforced in the database, not the interface.

An anonymous visitor can only ever read published, filed work, and the rule lives in the database rather than in the front end. Verified with the public key: the anonymous client sees none of the draft probes and cannot write.

L1Row-level securityPublished and filed work is readable by anyone. Drafts and unfiled pieces are invisible to the anonymous key, and anonymous writes are refused.

L2Limits as database rulesThe feedback button on every page writes to a Studio inbox, capped by a database check and an hourly trigger, not by a client-side guard that can be bypassed.

L3Keepalive with a visible heartbeatFree-tier databases pause when idle and need a manual click to wake. A twice-daily job does a real read and write, and the last heartbeat is shown in the Studio so a silent failure is visible.

L4Stale-tab detectionThe page notices a newer build and offers a refresh instead of silently running old code.

04 · what went wrong, and what it taught

A blank page with no error.

Bumping the local database version hung the page forever while another tab held the old version. It rendered blank with zero console output, the same symptom as her original complaint. It is now handled explicitly, with a visible error state, and the lesson is that a silent failure is the worst kind.

L1The symptomA blank page, no error, no warning. Indistinguishable from the broken site she started with.

L2The causeA version bump blocks the database open call while an older tab still holds the previous version.

L3The fixHandle the blocked and version-change events, and show a real error state instead of nothing.

L4The rule that came out of itMeasured, not eyeballed: two mobile Studio bugs were caught the same way, by reading the numbers rather than trusting the screen.