1
0 Comments

I built a File Delivery SaaS in 15 days — here’s why existing tools fail (with real workflow breakdown)

Most file sharing tools are optimized for storage.

But most people use them to deliver work.

That mismatch creates a lot more friction than people realize.

So I tried to break it down.


The actual workflow problem (based on observation)

A typical freelancer workflow looks like this:

  1. Create file
  2. Upload to Drive / Dropbox / WeTransfer
  3. Share link
  4. Make changes
  5. Re-upload
  6. Re-share
  7. Explain what changed

Repeat this 3–10 times per project.

The hidden cost:

  • Time wasted resending
  • Client confusion
  • Version mistakes

This is not edge-case behavior.

It’s the default.


Quick comparison of common tools

Google Drive / Dropbox

  • Built for: storage & collaboration

  • Problem:

    • Permission friction
    • Folder exposure
    • Version clarity is poor for clients

WeTransfer / SendAnywhere

  • Built for: one-time transfers

  • Problem:

    • Links expire
    • Every update = new upload + new link
    • No continuity

Loom

  • Built for: explaining work

  • Problem:

    • Not actual file delivery
    • Still requires sending files separately

What none of them solve

They don’t solve:

→ “How do I deliver evolving work to a client without confusion?”

That’s the gap.


The alternative approach I tested

Instead of:
“send file → resend file → resend again”

I flipped it to:

→ One permanent link per deliverable
→ File updates behind the same link
→ Client always sees latest version

No re-sending.


What I built (Clowd)

Clowd is built around that single workflow:

  • One link per file
  • Update anytime
  • No login required for clients
  • Version history built-in

That’s it.

No folders. No complexity.


Build time vs actual difficulty

Built in 15 days using AI.

Breakdown:

  • ~60–70% faster development (UI, logic, debugging)
  • Near-zero time stuck on small issues

But:

AI didn’t help with:

  • Identifying this workflow gap
  • Positioning (delivery vs storage)
  • Deciding what to exclude

That part still took most of the thinking.


Where this could fail

Being realistic:

  • People are used to existing tools
  • “Good enough” solutions are hard to replace
  • This might be seen as a small improvement, not a must-have

That’s the risk.


Early experiment: distribution

Testing a simple referral loop:

  • $1 per signup
  • Friend gets $1 instantly
  • 50 referrals = free Pro for a year

Hypothesis:
Early users have the highest incentive to share.

Not sure if this will compound yet.


Key insight so far

The biggest shift isn’t technical.

It’s conceptual:

Storage ≠ Delivery

Most tools solve the first.

Very few solve the second.


Open questions

I’m trying to validate:

  • Is this a real pain or just a mild annoyance?
  • Would you switch tools for this?
  • What would make this a “must-have”?

If you want to see what I mean:
https://clowd.store

Would genuinely value critical feedback.

on April 7, 2026
Trending on Indie Hackers
I shipped a productivity SaaS in 30 days as a solo dev — here's what AI actually changed (and what it didn't) User Avatar 261 comments Never hire an SEO Agency for your Saas Startup User Avatar 108 comments A simple way to keep AI automations from making bad decisions User Avatar 72 comments 85% of visitors leave our pricing page without buying. sharing our raw funnel data User Avatar 45 comments Are indie makers actually bad customers? User Avatar 40 comments We automated our business vetting with OpenClaw User Avatar 38 comments