Expiry belongs to the share
The lifetime is part of creating the link, not a separate cleanup preference that has to be remembered later.
Ventry case study
Ventry was developed from 2023 to 2024 around a direct promise: share a file through a link, give that link an expiry, and remove the file automatically when its time is up.
Visit VentryMany file-sharing links outlive the moment they were created for. That leaves the sender responsible for remembering where a file is hosted and when it should no longer be available.
Ventry tied access to a defined expiry and paired that expiry with automatic file removal, so temporary sharing did not depend on a later manual cleanup step.
I built Ventry from 2023 to 2024 as a TypeScript and Next.js project. The portfolio records that period as completed work rather than implying current development.
My work centered on the browser flow for uploading a file, creating a shareable link and making the expiry visible as part of the sharing lifecycle.
The lifetime is part of creating the link, not a separate cleanup preference that has to be remembered later.
An expired link and its stored file are treated as one state transition so access and retention do not drift apart.
The core interaction stays focused on the file, its expiry and the resulting link rather than adding unrelated project-management features.
Ending access is only half of the promise. The stored file also has to follow the same expiry so a dead link does not leave forgotten data behind.
Expiry is time-driven rather than triggered by the sender returning to the site, so removal cannot rely on a later manual interaction.