DEV Community: TiniDrop

Stop attaching your pitch deck. Send a secure view-only link instead

TiniDrop — Sun, 08 Nov 2026 18:27:12 +0000

You finish the deck. You hit send. The PDF leaves as an attachment.

Now three things are true at once:

You do not know if they opened it
An old version can live forever in someone’s inbox
Anyone they forward it to gets a full copy

That is not fundraising. That is hoping.

This guide shows a cleaner habit used by teams that treat the deck like a secure handoff, not a file dump: upload once → share a view-only link → see who opened it → follow up with context.

I built this loop into TiniDrop because I kept losing control of the PDF the moment it left the email. The steps below work whether you use TiniDrop or any secure link tool — the point is the workflow.

Quick guide

Upload the pitch deck (PDF)
Turn on view-only + optional password / expiry
Copy the secure link
Send the link (not the file)
Check opens, then follow up with a specific note

Why a secure link beats an attachment

Control stays with you.

An attachment is a clone. A link is a door you can tighten: view-only, password, expiry.

You see signal, not silence.

Opens and time on page tell you who is actually reading — so you stop chasing cold silence and start following warm opens.

One source of truth.

Update the file behind the same link when numbers change. You are not hunting “final_v7_REALLY_final.pdf” across threads.

Professional for the recipient.

They open in the browser. No 12 MB attachment blocked by IT. No “can you resend?”

DocSend and Papermark popularized this pattern for a reason. The product category is the same idea: secure document intelligence — share the file as a link, keep the original, see who engaged.

Step 1 — Upload the deck

Export a clean PDF (one deck, not a ZIP of drafts).

Sign in at tinidrop.com
Drop the PDF on the upload area
Wait for the share link

Free is enough to try the loop. Paid plans unlock longer retention, larger files, and API upload if you automate exports later.

Step 2 — Make the link secure

Before you paste the URL into an investor email, tighten it:

View-only — they can read in the browser; they do not walk away with your “source” file as the default habit
Password — useful for a cold intro or a sensitive round; send the password in a separate message
Expiry — match the round. If the raise has a date, the link can too

You still cannot stop screenshots. You can stop blindly shipping the original into every inbox forever.

That is the “secure” part people actually feel: fewer uncontrolled copies, clearer access window.

Step 3 — Create separate links when it matters

One link for the whole world is fine for a soft preview.

For a real raise, prefer one link per firm or per partner when you can. Then engagement maps to a conversation, not a mystery open.

Same idea DocSend users rely on: the link is the unit of tracking, not the email pixel.

Step 4 — Send the link, not the PDF

In the email:

One short paragraph on why you are reaching out
The secure link
One clear ask (15-minute call, intro, feedback on slide X)

Avoid burying the link under five attachments. The deck is the link.

Example shape (adapt freely):

Hi Name — sharing our seed deck as a secure view-only link (not an attachment). Happy to walk through the traction slide live if useful:

https://tinidrop.com/view/…

Open to a 15-min call next week?

Step 5 — Read the opens, then follow up like a human

After you send:

Check whether the link was opened
Note time on page if you have it
Follow up with something specific — not “just checking if you got this”

Good follow-ups sound like:

“Saw you spent time on the go-to-market section — happy to send the deeper funnel notes.”
“If the deck is still in the pile, the one-pager on unit economics is slide 8.”

Bad follow-ups sound like calendar spam with zero signal.

Best practices that actually sell the round

Personalize the wrapper, not the vanity URL.

The email is personal. The link is secure and trackable.

Protect what is sensitive.

Financials, customer names, unreleased product — password + expiry are cheap insurance.

Do not confuse Git with a handoff.

Investors are not cloning your repo. Clients are not joining your Notion. A secure link is the right tool for a finished PDF.

Keep the stack out of the story.

Founders buy outcomes: control, opens, fewer awkward resends — not infrastructure brand names.

FAQ

Is a link safer than emailing a PDF?

Safer for control. You decide view-only, password, and expiry. An attachment is an uncontrolled copy the second it leaves.

Can recipients open it without an account?

Yes — they open the link in a browser.

What if they forward the link?

Treat the URL like a door. Password + expiry limit the blast radius. For high-stakes rooms, use a tighter access pattern and shorter expiry.

Can I update the deck after sending?

Replace the file behind the same share when your product allows it — or send a fresh link and retire the old one with expiry. Never leave “old numbers” living as an attachment forever.

Is this only for pitch decks?

Same loop works for proposals, board packs, client PDFs, and small HTML/ZIP previews. The habit is identical: link, not attachment.

Start here

Open tinidrop.com
Drop your deck
Turn on the secure settings you need
Paste the link into the next investor email
Follow the opens, not the silence

I am Santosh, co-founder of TiniDrop in Würzburg. We build secure document intelligence for modern teams — share a file with a link, track who opened it, keep it view-only. If your last raise still ran on attachments, say what you send (deck, data room PDF, client proposal) in the comments and we can compare notes on the handoff.

Replace email attachments in CI — upload a ZIP from GitHub Actions and get a shareable link

TiniDrop — Sun, 08 Nov 2026 18:14:25 +0000

Your CI already builds the artifact.

Then someone pastes it into Slack as a 40 MB attachment — or opens a throwaway Google Drive link that expires next week with no signal that anyone opened it.

If the person on the other end is not living in GitHub Releases, you need a handoff link: one URL, browser-readable, optional password/expiry, and a simple “was it opened?” check.

This post walks through a practical pattern:

Build a ZIP (or PDF) in GitHub Actions
Upload it with one authenticated curl
Post the share URL back on the PR (or into Slack)

I use TiniDrop for the share step because that is what we built for this exact loop — but the workflow shape is the same idea wherever you land the file: artifact in CI → link out → humans click a URL, not a binary.

When this beats GitHub Releases (and email)

Use a share link when:

The recipient is a client, investor, or teammate who is not cloning repos
You are shipping a finished ZIP / PDF / HTML preview, not ongoing source
You want a lightweight “did they open it?” signal after the PR merges
You might want a password or expiry on that one URL

Keep Releases for versioned open-source downloads. Use a link for the human handoff.

What you need

A GitHub repo with Actions enabled
A ZIP (or PDF) produced by your job — dist.zip, site.zip, deck.pdf, etc.
A TiniDrop account on Solo or Pro (API keys live under Dashboard → Settings → API keys)
An API key stored as a GitHub Actions secret — never in the repo

Generate the key once in the dashboard. Name it something like github-actions-ci. Copy it only at creation time.

Add a repository secret:

Name: TINIDROP_API_KEY
Value: the key (starts with td_ if you created it recently)

Minimal upload from your laptop (sanity check)

Before wiring Actions, prove the API from your machine:

curl -sS -X POST https://tinidrop.com/api/upload \
  -H "x-api-key: $TINIDROP_API_KEY" \
  -F "file=@dist.zip"

A successful response includes a shareable url (and a slug). Shape:

{
  "slug": "a8k2mx",
  "url": "https://tinidrop.com/view/a8k2mx",
  "original_name": "dist.zip",
  "size_bytes": 1843200
}

Open that url in a private window. If it loads, you are ready for CI.

Note: API upload is for Solo / Pro. Free-plan uploads go through the browser (bot check). Put the key in CI secrets and rotate it if it ever leaks — same hygiene as any deploy token.

GitHub Actions: upload after build

Here is a job that builds, zips, uploads, and prints the link.

name: Share build as link

on:
  workflow_dispatch:
  push:
    branches: [main]

jobs:
  share:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build
        run: |
          # replace with your real build
          mkdir -p dist
          echo "<h1>Preview</h1>" > dist/index.html

      - name: Zip artifact
        run: |
          cd dist && zip -r ../dist.zip .

      - name: Upload to TiniDrop
        id: upload
        env:
          TINIDROP_API_KEY: ${{ secrets.TINIDROP_API_KEY }}
        run: |
          set -euo pipefail
          RESP=$(curl -sS -X POST https://tinidrop.com/api/upload \
            -H "x-api-key: ${TINIDROP_API_KEY}" \
            -F "file=@dist.zip")
          echo "$RESP" | tee upload.json
          URL=$(echo "$RESP" | jq -r '.url')
          if [ -z "$URL" ] || [ "$URL" = "null" ]; then
            echo "Upload failed — check API key and plan"
            exit 1
          fi
          echo "url=$URL" >> "$GITHUB_OUTPUT"
          echo "Share URL: $URL"

      - name: Summary
        run: |
          echo "### Build ready" >> "$GITHUB_STEP_SUMMARY"
          echo "[Open share link](${{ steps.upload.outputs.url }})" >> "$GITHUB_STEP_SUMMARY"

What this gives you:

A green check on main (or manual dispatch)
A clickable link in the Actions job summary
No attachment bouncing through email size limits

Bonus: comment the link on the pull request

Useful when reviewers are not watching the Actions tab:

name: PR preview link

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  preview:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4

      - name: Build + zip
        run: |
          mkdir -p dist && cp -R public/* dist/ || true
          # your build here…
          cd dist && zip -r ../preview.zip .

      - name: Upload
        id: upload
        env:
          TINIDROP_API_KEY: ${{ secrets.TINIDROP_API_KEY }}
        run: |
          RESP=$(curl -sS -X POST https://tinidrop.com/api/upload \
            -H "x-api-key: ${TINIDROP_API_KEY}" \
            -F "file=@preview.zip")
          URL=$(echo "$RESP" | jq -r '.url')
          echo "url=$URL" >> "$GITHUB_OUTPUT"

      - name: Comment on PR
        uses: actions/github-script@v7
        with:
          script: |
            const url = '${{ steps.upload.outputs.url }}';
            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: `### Preview ready\n\nOpen the share link (view in browser):\n${url}`
            });

Reviewers click once. They do not need a GitHub package download or a local unzip ritual.

PDF decks and client ZIPs

Same pattern, different artifact:

Pitch / proposal PDF — export in CI or commit the latest PDF, upload, send the link before the call
Client deliverable ZIP — zip the folder after npm run build, upload, paste into email
HTML prototype — zip a folder that contains index.html; the share link opens in the browser

After you send it, check whether it was opened, then follow up with a specific next step — not “just checking if you got this.”

Hardening checklist

[ ] Secret is TINIDROP_API_KEY in GitHub — never in YAML
[ ] Key is Solo/Pro; rotate if a fork PR could have read it (prefer environment secrets with approval for forks)
[ ] Fail the job if .url is missing — do not silently “succeed” with a broken handoff
[ ] For sensitive rounds, set password and expiry on the link from the dashboard after upload
[ ] Do not treat a share link as a substitute for Git — source stays in the repo

FAQ

Do recipients need an account?

No. They open the link in a browser.

Is this a replacement for GitHub Releases?

No. Releases win for public versioned downloads. This wins for fast, private-ish handoffs to non-Git audiences.

What file types?

PDF, ZIP, HTML/HTM, and common images. Keep the ZIP for small static previews; keep Git for real collaboration.

Where do I start without CI?

tinidrop.com → drop a file → copy the link. Wire Actions once the manual loop feels right.

I am Santosh, co-founder of TiniDrop (Würzburg). If your team still pastes build ZIPs into Slack as attachments, say what you ship in the comments — CI preview, client ZIP, or deck — and we can compare notes on the handoff.

How to share a ZIP or PDF with a link (and upload via API)

TiniDrop — Wed, 14 Oct 2026 15:02:23 +0000

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.

Document rooms that tell you who opened the file

TiniDrop — Sat, 03 Oct 2026 16:12:49 +0000

A data room used to mean a vendor, a week of setup, and a folder tree nobody wanted to maintain.

Founders still need the same job: put the important files in one place, send one link, know who went in.

That is a document room. Not a second Dropbox. A room with a pulse.

One room. Many files. One story.

In TiniDrop a room holds the files for a deal, a hire, a client, or a round.

You do not email five attachments and hope they land in the same thread. You send the room. The other side opens what they need. You see which files they opened, how long they stayed, and whether they came back.

That changes the follow-up:

They spent twelve minutes on the model and skipped the deck → talk numbers.
They never opened the NDA → do not pitch the product yet.
They returned twice after the call → they are still in.

Controls that belong on the link, not in a PDF

Rooms only work if the link is not a zip of copies.

On a TiniDrop room you can:

keep files view-only
password the link
expire access when the process ends
separate who can see which file
watch activity instead of guessing

The file never has to leave. The room can be unplugged.

Who this is for

Not "enterprise content platforms."

a founder sending a round
an agency handing a delivery
a lawyer sharing a draft
a hiring manager sending a take-home that should not leak

If you have more than one file and you care who opened it, you already have a room. You are just running it in Gmail.

Start with one deal

Pick the next process that would hurt if the files leaked or sat unread.

Put them in a room. Send the link. Watch what happens after you send.

tinidrop.com

View-only sharing — they can read it. They don't get the original.

TiniDrop — Sat, 03 Oct 2026 16:06:27 +0000

Most "secure sharing" still gives the other person a file.

They click. The browser downloads. Now there are two copies. Then twenty, if they forward it.

View-only sharing is the opposite idea: the document renders in the browser. The original stays with you.

What view-only actually does

On TiniDrop, view-only means we hide the download control on the shared link (Solo and above). The recipient reads the PDF in the viewer. They do not get a one-click .pdf.

What it does not do:

stop a screenshot
stop someone photographing the screen
stop a determined person with developer tools

Anyone who claims otherwise is selling you a feeling. We would rather be precise.

View-only is for the common case: a founder, a lawyer, an agency client, a hiring manager. People who will not reverse-engineer your viewer. People who will hit Download if you put the button there.

Why the viewer has to be the product

If the fallback is "download to open," view-only is fake.

The link has to open a real reading experience:

PDFs in the browser
HTML and ZIP sites as a live page
images without a save prompt as the first action

Then the share is a session, not a file transfer. Analytics attach to that session. Password and expiry attach to that session. You can kill the link without asking anyone to delete an attachment they already have.

When I turn it on

fundraising decks
unreleased product specs
contractor briefs
anything I would regret seeing in a Slack screenshot tomorrow with my filename on it

When I want a signature, I do not use view-only as the close. I send an agreement on the same file. Read, then sign. Still one link.

Try the difference

Upload a PDF you would normally attach. Share the link. Turn download off.

They can read it. They don't get the original.

tinidrop.com

What happens after you send the deck

TiniDrop — Sat, 03 Oct 2026 15:59:31 +0000

You send the pitch. Then you wait.

Was it opened? Did they skim slide one and bounce? Did they come back at 11pm and sit on the financials?

Email cannot tell you. Drive "anyone with the link" cannot tell you. WhatsApp definitely cannot tell you.

Silence is not a signal. Silence is missing data.

The file is not the product. The session is.

A shared document has a life after send:

first open
time on page
which pages they actually read
whether they came back
whether they downloaded a copy

That is the conversation. The PDF is just the medium.

TiniDrop records that session on every shared link. You see when someone opened it. On higher plans you see page-level time, email alerts when they show up, and who came through a personalised link.

You follow up because they read it — or you stop chasing because they did not.

A link you can unplug

Attachments cannot be recalled. Links can.

If the round closed, the contractor finished, or the wrong person got the URL, you expire it. You password it. You turn download off.

View-only is not a vault. A determined person can still photograph a screen. Treat it as friction: enough that a casual forward does not hand over the original.

That is the correct security model for a deck, not theatre.

After you send, you should know

The product thesis is one sentence:

Share a file. See who opened it. Keep it view-only.

Everything else — rooms, signatures, watermarks — is that sentence under more pressure.

If you send work that matters, stop treating "delivered" as "read."

Start here: tinidrop.com

I stopped attaching the file. I send a link instead.

TiniDrop — Sat, 03 Oct 2026 15:58:31 +0000

Every important file I sent used to leave as an attachment.

Pitch deck. Proposal. Contract. A ZIP of a prototype.

The other person got a copy. I lost the original the moment I hit send. If they forwarded it, I would never know. If they never opened it, I would sit in the dark and follow up anyway.

That is a bad way to run a deal. It is also how almost everyone still shares work.

The attachment is the product leaving the building

An email attachment is not a share. It is a handoff.

Once the PDF sits in someone else's Downloads folder, you cannot:

see whether they opened it
see how long they stayed
stop a casual download
take the link back if the round moved on

You can send a newer version. They will still have the old one. You can write "confidential" on slide one. That does not make the file confidential.

I built TiniDrop for the moment after send — the part most tools ignore.

One link. The file stays with you.

The workflow is intentionally small:

Drop a PDF, ZIP, HTML page, or image.
Get a short link.
Share the link. Not the file.

The recipient opens it in the browser. You keep the original.

On paid plans you can turn the link view-only, add a password, set expiry, and see who opened it. Free is enough to feel the difference: a live URL in seconds, a view count, no infrastructure.

What I refused to build

I did not want another "all-in-one workspace."

Founders do not need a CMS to send a deck. Agencies do not need a VPS to show a client a page. Students do not need Git to host an HTML assignment.

They need a clean URL, a viewer that actually renders, and a way to know the other side showed up.

TiniDrop is document intelligence for that moment:

Share — a link instead of an attachment
Track — opens, time on page, return visits
Control — view-only, password, expiry, document rooms

Try it

Upload something you would normally attach.

tinidrop.com

If the link feels better than the attachment, you already understand the product.