Magrathea Software ← Blog

Field Notes

Your galleries go quiet. Your storage bill doesn't.

11 August 2026 · Kyle Twogood, Magrathea Software

A delivered gallery has a shape to its life. It is opened by every family in the first week, a few stragglers in the first month, and then almost nobody, forever. The bytes stay exactly as expensive on day 900 as they were on day one, because every gallery platform prices storage as a flat rate regardless of whether anyone is looking. This is the design work behind pricing a gallery by its age instead: the storage mechanism, the fees that ambush you, and the honest arithmetic on when the whole idea fails to pay.


The access curve nobody prices

Ask a working photographer when a gallery gets viewed and you get a very confident answer: the week it lands. Recital and event galleries are the extreme case, since the audience is a fixed roster of families who all get the link on the same day, but portrait galleries behave the same way with a longer tail. Access is hot for roughly 60 to 90 days after delivery, then near-dead, with occasional reopenings years later when someone wants a print or a slideshow for a graduation.

That is a predictable, event-driven decay curve, and it is the single most useful fact about the workload. Nothing in the category's pricing reflects it.

So the back catalog becomes the tax. It is the part of a photographer's storage that grows every year, gets accessed the least, and costs the most in aggregate. It is also the part they are least willing to delete, because deleting it means telling a family that the 2019 recital is gone.

Three ways the category handles it, none of which is pricing

When I surveyed the delivery platforms in July 2026, the responses to the back-catalog problem sorted into three buckets:

What none of them do is pass archive-tier economics through to the customer, and the reason is structural rather than technical. Their storage ladder is the revenue model. A tier that made old galleries nearly free would cannibalize the upsell that pays for the company. This is the rare case where a competitor can see exactly what you are doing, agree that it is better, and still not follow.

The mechanism: explicit lifecycle rules, not Intelligent-Tiering

The AWS rates that make this work, us-east-1, verified against the pricing page on 11 August 2026:

ClassPer GB-monthAccessMinimums
S3 Standard$0.023millisecondsnone
Glacier Instant Retrieval$0.004milliseconds, $0.03/GB retrieval90 days, 128 KB
Glacier Deep Archive$0.00099restore, hours180 days, 40 KB overhead

Glacier Instant Retrieval is the interesting one, and it is routinely misread as an archive tier you have to thaw. You do not. It serves objects in milliseconds, exactly like Standard, at a bit under a fifth of the price, and charges you three cents a gigabyte when you actually read them. For data that is browsed rarely but must appear instantly when it is, that trade is close to perfect.

The obvious-looking alternative is Intelligent-Tiering: let AWS watch the access pattern and move objects for you. For this workload it is the wrong tool, for three reasons.

So the rule is written by hand, per prefix, against the calendar:

Standard
  → Glacier Instant Retrieval   at day 90   (season is over)
  → Glacier Deep Archive        at day 730  (the forever archive)

Two more things the transition has to respect. The minimums are real: an object moved to Glacier IR and deleted at day 30 still bills for the full 90 days, so a lifecycle rule that races a retention policy costs more than doing nothing. And transitions are billed per object request, which means tiering a million thumbnails has a real one-time cost against a saving measured in cents.

Which is why the small files stay hot

Glacier IR bills any object under 128 KB as though it were 128 KB. A 20 KB thumbnail therefore does not get 5.75x cheaper when you archive it. It gets billed at 6.4x its own size in a tier that is 5.75x cheaper, which is a rounding error of a saving, and now the grid view that renders 400 of them pays a retrieval fee every time somebody scrolls.

The rule that falls out of this is worth stating plainly, because it is the opposite of the intuition that cold storage is for everything old: tier by object size and role, not just by age. Originals and full-size downloads are big, rarely fetched, and belong in the cold tier. Thumbnails and web renditions are small, fetched in bulk the moment anyone opens the page at all, and belong in Standard forever. The archive saves money on the bytes that constitute the archive, and the browsing experience of a ten-year-old gallery is indistinguishable from a new one.

The honest math, including where it loses

Here is the part that most storage-economics posts skip. Cold tiering is not free money, and for a photographer with a small active catalog it is not even a saving.

My own numbers: I pay $99.99 a year for 2 TB of Google One, which is about $4.17 per terabyte-month at full utilization. Glacier IR is $4.10. Migrating my current catalog to a cold tier saves me somewhere between nothing and three dollars a month, and S3 Standard is roughly 4.7x the price of Drive, so any bytes that stay hot make it actively worse.

Consumer cloud storage is genuinely cheap. What it is not is linear. The case for lifecycle pricing does not activate on rate, it activates on the shape of the curve:

The discipline this imposed on the product: the mechanism goes on the marketing page, the price does not. Our price corridor is still unverified, so quoting it would be inventing a number that a photographer could hold us to. Argue the mechanism, and let the number arrive when it has been tested.

Restore as an event, not a punishment

Deep Archive's cost comes with a latency of hours, which sounds like the thing that kills the design. It is not, as long as the delay is expected. The same wait is a great experience or an outage depending entirely on whether the person knew it was coming.

A surprise archive is: family clicks a link from 2019, gets an error or a dead gallery, emails the photographer, photographer discovers their platform archived it. A requested restore is: family clicks a link from 2019, sees a page that says these photographs are in the long-term archive, asks for them back, and gets an email when they are ready. Same latency. Opposite feeling.

The genuinely interesting part is what the request is. Somebody just raised their hand and said they want their 2019 photographs, and attached their contact details to the request. That is a print sale or a rebooking lead landing in the studio's inbox. One competitor has built the restore-request flow and, when we checked in July 2026, its owner notification does not even pass the requester's contact information through. The email is collected only to notify the requester when the restore finishes. The lead exists in their system and nobody surfaces it.

That is the pattern I keep finding in this category. The expensive infrastructure work is done; the product thinking around it is not.

What is actually built

Being precise, because a design post is easy to mistake for a shipping announcement. Kept is in preview with real galleries and real families on it. The lifecycle argument is the lead story on its pitch, and the storage architecture is built to accommodate the tiering described here. Age-based pricing is deliberately out of the MVP, and no price appears anywhere on the site.

What I will not do is ship the pricing model before the restore experience is good, since the entire promise depends on the cold tier being invisible when someone wants their photographs back. Cheap storage that makes the 2019 recital feel gone is worse than expensive storage that keeps it one click away.

The takeaway

If your product stores media that people stop looking at:

  • Find the decay curve and check whether your pricing knows about it
  • Use explicit lifecycle rules when access is predictable; reserve Intelligent-Tiering for patterns you genuinely cannot forecast
  • Tier by size and role, not only age. Small objects and the ones that render the page stay hot
  • Price the retrieval, the minimums, and the per-object transitions, not just the headline per-gigabyte rate
  • Make the wait an event the user chose, and read the request as the demand signal it is

Storage rates change and mine were verified the day this was published. The decay curve will not change, and neither will the fact that almost nobody is billing for it.

Kyle Twogood

Kyle Twogood is the founder of Magrathea Software. He’s been building production software since 1997.