When 7-day self-destruct is the wrong default (and when it's perfect)

You send the client a link to the deliverable on Friday — created in seconds, visible only to who you sent it to. They open it Monday, send notes, you revise. Tuesday the next-version link goes out. By next month the original link is gone; that's correct — it was a draft, the conversation moved on, the work product lives in the next link.

Same flow, different file: you send a VC the pitch deck Friday before the partner meeting. They re-open it Tuesday, then again three weeks later when running it past a second partner, then a month after that when introducing you to a follow-on fund. By month two the link is dead. The deck wasn't a draft; it was a reference.

Same shape of object, different shape of engagement. The expiry choice maps to the second one, not the first.

What 7-day self-destruct is actually for

Storage on the anonymous tier of a private-link service is a shared resource. If every one-off upload lived forever, the storage bill would compound across millions of test runs, abandoned drafts, and "I'll come back to this" links that nobody comes back to. A self-destruct default cleans the table without anyone having to remember.

For the typical one-off case — drop a file, send the link, the receiver looks once, the engagement ends in the same week — 7 days is genuinely the right shape. The link stays alive across the obvious review windows (weekend, next business day, the meeting it's referenced in) and clears before it becomes archived clutter.

It's the design that matches the use, not a limitation imposed on the use.

When permanent is the right shape

Some links are made to outlive the moment they're sent. The pattern is roughly:

• External reference linked from somewhere else. The case study lives at a URL the client features on their own site; the link going dead means a 404 on someone else's page. Permanent.
• Long-tail document the receiver returns to. A pitch deck, a research report, a methodology explainer — the original viewer comes back; new viewers get forwarded the URL. Permanent.
• Portfolio or bio link. A freelancer or studio links the work from their About page; the link is part of their professional surface. Permanent.
• Archive of a past engagement. A quarterly review that the team references when planning the next quarter; the file is correct for that quarter and stays correct as a historical record. Permanent.

In each of these, the value of the link is its stability over time. An expiry default in this shape isn't a clean-up; it's a broken link in someone else's workflow.

When expiry is right — but a custom one

There's also a middle case where neither default fits: the link should outlive the moment it's sent, but only by a known window. A few patterns:

• Quarterly business review. The numbers are correct for the quarter, misleading afterward. 90-day expiry matches the engagement window.
• Conference talk handout. The link is shared after the talk; the speaker wants it live for the next month of follow-up but not forever as the audience changes. 30-day expiry.
• NDA-bound diligence document. The investor is reviewing for a deal; once the deal closes or falls through, the link should retire. Custom expiry matching the deal calendar.

For these, a configurable expiry — pick the date, the link dies that day — is the shape that fits. Neither "7 days" nor "forever" is the answer; the engagement's natural end date is.

The pricing shape mirrors the engagement shape

Most private-link tools structure their plan ladders around this exact question, even when the marketing copy doesn't say it directly.

• Anonymous / Free tier — 7-day default. Sized for the one-off case (try-it-out, drop-and-send, single receiver). The expiry is part of the design, not a paywall taunt.
• Paid tier — permanent links + custom expiry windows. Sized for the cases where the link is part of an ongoing artifact — proposals, references, portfolios, board archives. The cost recovers the storage of files that don't self-clean.

For an AI artifact sent to one client for review, the Free tier's 7-day default usually fits — the deliverable cycle is bounded, the link is a single delivery moment, the file going away is correct after sign-off.

For a finished agency preview that becomes part of the case-study archive, permanent is the right shape — the link lives at the studio's URL bar from then on, referenced from the next pitch deck and the next portfolio update.

Where permanent is the wrong choice

Not every file should live forever, even if the engagement supports it. Two cases where an expiry — even on a paid plan — is the right call:

• Time-sensitive numbers. A consulting report that includes Q3 data is correct in October and misleading by February. A 90-day expiry forces the conversation about whether to renew with refreshed data, instead of letting a stale link become the "current" reference by accident.
• Pre-announcement material. A product reveal deck shared with reviewers under NDA needs to retire on launch day — the post-launch version is the public marketing page, not the leaked pre-version. A specific-date expiry handles this cleanly.

Permanent is the right default for most paid use cases. It's not the right default for every paid use case; the option to override per link is the part that matters.

Picking without overthinking

Two questions, in order:

1. Will anyone open this link more than a week after I send it?

   • No — 7-day default is fine, anonymous/Free tier covers it.
   • Yes — permanent (or a date-specific expiry matching the engagement).

2. If permanent, does the file include numbers that go stale?

   • No — permanent.
   • Yes — custom expiry matching the freshness window of the data.

That's the decision. Most one-off review cycles answer "no, no" and ship on the default. Most reference material answers "yes, no" and goes permanent. Most time-sensitive analysis answers "yes, yes" and gets a custom expiry that maps to the data's shelf life.

If question 1 is the one you can't answer confidently, the link's own numbers usually can — reading a private link's access log covers how to tell one person re-opening a page from several people finding it, which is exactly the signal that decides whether the window should stay open.

And if the reason you're reaching for an expiry is that the contents are sensitive, expiry is the weaker of the two tools available. What password protection on a link actually does — and the meaningful difference between a real server-side gate and a prompt drawn after the file already arrived — is worth understanding before you rely on either.