You finish a build. You have a ZIP, a PDF deck, or a small HTML folder. Someone needs it today — a client, a teammate, a reviewer.
Opening a Git repo for that is overkill. Emailing a 40 MB attachment is how files get lost in spam and forwards.
Here is a practical how-to: turn the file into a link, optionally see if it was opened, and (if you automate builds) upload it with a short API call.
I built this flow into TiniDrop because I kept hitting the same wall as a founder in Würzburg: the work was done, the handoff was the painful part.
When a link beats Git (and email)
Use a share link when:
- The other person is not living in GitHub
- You are handing off a finished ZIP / PDF / prototype, not an ongoing repo
- You want a simple “did they open it?” signal
- You might want a password or an expiry on that one link
Keep Git for real source control. Use a link for the handoff.
How to share a file in three steps
- Open tinidrop.com and sign in (a free account is enough to try).
- Drop your PDF, ZIP, HTML, or image onto the upload area.
- Copy the link. Send that in email, Slack, or Teams — not the attachment.
The recipient opens it in the browser. You keep the original file.
That is the whole loop for most people. No deploy pipeline. No “please make a GitHub account.”
Optional: password and expiry
For a deal round or a client preview, tighten the link:
- Add a password if the URL might get forwarded
- Set an expiry if the round has an end date
You do not need enterprise software for that. You need a link that matches the conversation you are having.
Optional: upload from a script (API)
If your artifact already exists after CI, skip the UI and upload from a shell step.
Generate an API key from your TiniDrop dashboard (available on Solo / Pro), then:
curl -X POST https://tinidrop.com/api/upload \
-H "x-api-key: YOUR_API_KEY" \
-F "file=@dist.zip"
The JSON response includes a shareable URL. Example shape:
# pseudo: capture URL from the response, then notify
URL=$(curl -sS -X POST https://tinidrop.com/api/upload \
-H "x-api-key: $TINIDROP_API_KEY" \
-F "file=@dist.zip" | jq -r '.url')
echo "Build ready: $URL"
Useful for:
- Nightly build ZIPs
- Client-ready PDF exports after a docs job
- Distributing a small static preview without opening a new repo
Put the key in your CI secrets. Never commit it. Rotate it if it leaks — same hygiene as any other token.
PDF decks: send a link, then follow up with context
Pitch decks and proposals die in attachment land. A cleaner habit:
- Upload the PDF
- Send the link before the call
- After the call, check whether it was opened
- Follow up with a specific next step — not “just checking if you got this”
You still cannot stop screenshots. You can stop blindly shipping the original into every inbox.
ZIP of a small site
Got a folder with index.html? Zip it, upload, share the link. Handy for prototypes and client previews when “clone this repo” is the wrong ask.
Quick FAQ
Do recipients need an account?
No. They open the link.
Is this a replacement for GitHub Releases?
No. Releases win for ongoing open-source versioning. This wins for fast handoffs and non-Git audiences.
What about huge files?
Start on free for small ZIPs/PDFs. Step up a plan when you need larger uploads or longer-lived links. Pricing is on tinidrop.com/pricing.
Where do I start?
tinidrop.com → drop a file → copy the link. Wire the API later if your builds are already automated.
I am Santosh, co-founder of TiniDrop. If attachments keep failing your workflow — CI artifacts, client ZIPs, pitch decks — say what you are sending in the comments and we can compare notes.
Top comments (0)