Six posts, and every number in them comes from a run

Six posts, and every number in them comes from a run A series on why this exists and what building it taught us. Four posts on the problem — what the established platforms cost, why their archival story is usually unusable, where rights have to be enforced rather than displayed, and what changes when the storage is yours — then two on the implementation. No vendor is named anywhere. The problems described follow from the pricing model and from where the rights check sits, which makes them structural rather than anybody's particular failing, and naming names would make it a weaker argument as well as a rude one. **Every figure is from this repository rather than from a vendor's documentation.** The 76.7-second Glacier restore and the twenty-passed-none-skipped conformance run. The 608 objects lost and ~80 truncated when a disk filled, with the database reporting all of them healthy. The 1,280 index jobs never claimed once in thirty-five minutes. The 302 a delivery token gets when the tenant check is removed. The 4, 3 and 1 of 410 flaky browser tests across three runs. Each was verified against the code before it went in — the seven object-creating paths that carry the KMS key are seven because the test asserts that count, and the grid post's hundred thousand is the number in `AssetGrid.svelte.test.ts`. Several posts describe things we got wrong, and one describes a check that still does not catch the case it was written for. That is deliberate and the index says so: a series about a storage system that only described its successes would be making exactly the claim the fifth post argues against.