I built a desktop app to move files between cloud providers without subscriptions or CLI
I started working on this about a year ago because I needed to backup my GoPro footage to Backblaze B2. GoPro Cloud has no API, no bulk download, and no third-party tool support. The web app lets you grab 25 files at a time in zip bundles.
That turned into Blober, a desktop app that connects to 11 cloud storage providers and lets you transfer files between any two of them. AWS S3, Azure Blob, Google Drive, Dropbox, Backblaze B2, Cloudflare R2, DigitalOcean Spaces, Wasabi, Google Photos, GoPro Cloud, and local storage.
Why local-first
Every other cloud transfer tool I found was either a SaaS that routes your data through their servers or a CLI such as rclone that requires config files. I used custom scripts because I wanted my files to have a specific format:
backup/
├── 2025-12-24/
│ ├── 2025-12-24_08-24-02:DSC08007.jpg
│ └── 2025-12-24_09-15-45:IMG_1234.mp4
└── 2025-12-25/
├── 2025-12-25_10-05-30:HolidayPic.png
└── 2025-12-25_11-20-10:FamilyVideo.avi
Blober runs entirely on your machine. Files stream directly between provider APIs. Your credentials never leave your computer. No subscription, no transfer fees and definitely no transfer limits.
This matters for two reasons:
- Privacy. SaaS tools decrypt your data on their servers to relay it. Your credentials sit in their database.
- Cost. SaaS tools charge per-GB or monthly subscriptions. Blober is a one-time purchase. Transfer 100 GB or 100 TB, same price.
The hard parts
Google Photos changed their API policy in March 2025. Third-party apps can now only download photos they uploaded themselves. rclone broke overnight. Google's official answer is Takeout, which takes hours and gives you fragmented zips with no folder structure. I had to find a different approach to make it work in Blober.
GoPro Cloud has never had a public API. Building support for it was the most challenging integration because there's no documentation, no SDK, and no community resources.
Azure Blob mutations were an interesting addition. Beyond just moving files, Blober can change Azure storage tiers (Hot, Cool, Cold, Archive) and container access levels in bulk.
One-time purchase model means every sale is permanent revenue. No churn. But it also means no recurring revenue, so growth has to come from volume.
Currently supports Mac, Windows, and Linux.
As a developer with a very tiny online presence, marketing is the hard part. If you've built a utility tool and struggled with the marketing side, I'd love to hear what worked for you.
One thing I would add for desktop utilities: make the proof visual before you make it persuasive. A 20 second clip of GoPro Cloud to B2 with the local file path and transfer log visible will explain privacy, speed, and no CLI faster than another landing-page paragraph. Then turn each painful source/destination pair into its own page.
True... I already have several (https://blober.io/kb/docs/videos/gopro-cloud-workflow-setup/), perhaps I need to place them better on the website: https://www.youtube.com/watch?v=NTqqf4sKbpk
Lovely… If you are looking for contacts to help boost your sales and marketing... I have lists of high networth investors and could tailor customers that could either invest or boost customer sales. We have also helped founders get featured on Forbes, Bloomberg and many more. shoot me a message on telegram @caseyimafidon
One question: have you tested this with non-technical stakeholders submitting requests through Jotform? Curious how the "Definition of done" field holds up when someone without a dev background describes what they want changed. That seems like the potential friction point in an otherwise smooth pipeline.
I don't have a specific answer, but based on the structure you've already built, it's the same label, claim, and QR code — the marketing term is the same as the "optimized" version you've already built.
I can see the GoPro Cloud integration is particularly impressive.
Congrats on the launch of Blober, Kabui! As a fellow desktop application developer who has been running and maintaining an on-premise, pure buy-out B2B software for nearly 20 years, every single word you wrote resonates with me deeply.
The "SaaS fatigue" is very real, especially when it comes to handling massive files. People are finally waking up to the fact that routing terabytes of private data through a middleman's cloud server just to move it from provider A to B is both a security nightmare and a massive wallet drain. Your local-first approach streaming directly via APIs is the elegant, engineering-first solution. Respect for reverse-engineering the GoPro Cloud integration, too—dealing with undocumented APIs is a special kind of developer hell.
To answer your question about marketing a desktop utility tool with a small online presence: I’ve been in your shoes for a long time. Here is what actually works for our model over the long haul:
AlternativeTo is your highest-converting goldmine:
Submit Blober to the AlternativeTo platform immediately. Tag it explicitly with "local-first", "on-premise", and "lifetime license." List it as an alternative to MultCloud, Mover, and even rclone. There is a massive, underserved audience on that platform specifically searching for "SaaS alternatives without monthly fees." They are high-intent buyers ready to open their wallets for a one-time purchase.
Double down on "Pain-Point SEO" (Hyper-specific long-tail keywords):
Don't waste time trying to rank for broad keywords like "cloud file manager"—the VC-funded SaaS giants own those. Instead, create mini-landing pages or blog posts targeting the exact, painful technical brick walls you solved. For example: "How to bulk export GoPro Cloud footage to Backblaze B2" or "rclone alternative for Google Photos API workaround." When a user encounters the exact Google Photos or GoPro limitation you mentioned, they don't search for a general tool; they Google their specific frustration. If Blober shows up there, you win a customer instantly.
The one-time fee model is a marathon, not a sprint. You have to rely on volume and word-of-mouth, but building a solid, privacy-respecting utility that "just works" creates an incredibly loyal customer base.
Wishing you massive success with Blober. Let's keep the desktop buy-out movement alive!
Thank you, really appreciate advice, especially coming from someone who's been running the buy-out model for 20 years. That kind of longevity is exactly what makes me think this approach is the right bet for utility tools.
AlternativeTo is a great call. I will submit Blober there and tag it appropriately.
The pain-point SEO advice mirrors what has been working slowly. Articles targeting the exact frustrations ("how to bulk export GoPro Cloud footage to Backblaze B2", migrating from X to Y) perform better.
Thanks for taking the time to share what's worked.
The 'your files never touch our servers' architecture is a genuinely differentiated privacy positioning, especially now that enterprise compliance teams are increasingly uncomfortable with any vendor that can't demonstrate data isolation by design.
The thing that's interesting about the local-first + client-side architecture for cloud transfers specifically: once you close the gap between providers (which Blober does), the remaining friction is typically workflow integration. A team that wants to migrate from Google Drive to Backblaze B2 doesn't just need a transfer tool -- they need the downstream systems (shared links, embedded previews, access controls) to not break during transition.
For solopreneurs and small teams specifically, the tool I'd bet is most valuable here is the 'audit trail' use case -- being able to show a client or auditor that data moved from point A to point B at a specific time, with what permissions, through no third-party hands. That's the compliance story for the 1-3 person team that doesn't have an IT department.
Is there interest from your users in an audit log export per transfer? That might be a clean way to expand the value proposition without adding infrastructure complexity.
Good points. The permissions and sharing angle is interesting. You're right that a migration isn't really "done" if shared links and access controls break on the other side. That's worth exploring as providers allow it.
On audit trails: blober already has a transfer log that shows what moved, when, and whether it succeeded or failed. But adding richer attributes like permissions and sharing state per file is a natural extension that wouldn't add much complexity. No one's asked for it yet, but it feels like the kind of thing that'll matter once more teams start using it. It is worth anticipating rather than reacting to.
Appreciate the thoughtful feedback.
One question I'd love to ask: with the one-time purchase model (no recurring revenue), how are you thinking about sustainability and ongoing maintenance? Do you plan to release paid major versions over time, or is there another angle you're exploring?
The one-time price covers what's there today, and as the platform grows with more providers and features, the price goes up - so early users get a good deal.
Beyond that, am not overthinking it yet. Blober doesn't have heavy server costs since everything runs locally, so the pressure to find recurring revenue isn't as urgent as it would be for a SaaS. Focus right now is just making the tool genuinely useful enough that people genuinely prefer it and recommend it to others.
that's great!
thank you @cena5529
This is exactly the kind of tool that wins by solving one painful problem really well. The 'no subscriptions' angle is smart — that's the #1 complaint we hear about cloud tools. Have you thought about targeting developers who need to migrate large datasets between providers? That's a use case where people would pay a one-time fee without hesitation.
That's actually one of the stronger use cases already. The 100M+ files migration article gets decent traffic from people looking at exactly that scenario. With good internet speeds, Blober can move large dataset easily, and paying per-GB to a SaaS doesn't make sense.
Good to know the no-subscription angle resonates. Appreciate the feedback.
I do feel privacy first would be the way forward. I am a big believer of local desktop apps which only interact with cloud when needed. Wanted to understand how are you managing the costs or being able to have same cost for 100GB vs 100 Tb
Blober runs entirely on your machine. No data passes through our servers. Your files go straight from your computer to whatever cloud provider you're using.
On costs: since we don't proxy or store anything, our infrastructure costs are basically flat regardless of how much data you move. That's why the one-time pricing works, we're not scaling server costs with your usage.
yeah agree
Local-first + no subscription is the right call for a tool whose primary use case is bursty — "move my GoPro backup," "migrate Dropbox," then maybe nothing for 3 months. Subscriptions force users to either keep paying for a tool they aren't actively using, or churn and hit friction next time they need it. As a solo dev shipping a small iOS memo app (a Captio replacement), I've been making the same bet: utility apps with a bounded job feel better priced as a one-time unlock than a $4/mo subscription that triggers a "why am I still paying for this?" moment at month two.
Curious about the actual pricing decision — did you land on a single one-time license, tiered by provider count, or per-transfer credits? And how are you handling the discoverability problem desktop apps face without the SaaS-style trial funnel?
one-time payment is what I personally prefer from other products, so I'm more inclined to offer the same, especially for utility apps you don't use daily and that don't cost server loads. Otherwise you end up forcing a SaaS model and architecture onto something that doesn't need it. Single license, no tiers or credits. Didn't want people doing mental math about which plan covers their providers.
Right now Blober has a discounted price. As we keep adding features and providers, cost goes up as the platform grows, but early users lock in the lower price.
Discoverability is honestly the hard part. Mostly SEO. We publish articles around the specific pain points people search for (such as how to move GoPro Cloud media to Dropbox, backing up GoPro footage, backup Google Photos without google takeout, etc).
Good luck with the Captio replacement
Local-first + no subscription is the right call for a tool whose primary use case is bursty — "move my GoPro backup," "migrate Dropbox," then maybe nothing for 3 months. Subscriptions force users to either keep paying for a tool they aren't actively using, or churn and hit friction next time they need it. As a solo dev shipping a small iOS memo app (a Captio replacement), I've been making the same bet: utility apps with a bounded job feel better priced as a one-time unlock than a $4/mo subscription that triggers a "why am I still paying for this?" moment at month two.
Curious about the actual pricing decision — did you land on a single one-time license, tiered by provider count, or per-transfer credits? And how are you handling the discoverability problem desktop apps face without the SaaS-style trial funnel?
commented above: https://www.indiehackers.com/post/i-built-a-desktop-app-to-move-files-between-cloud-providers-without-subscriptions-or-cli-9f55ba396a?commentId=-Os_SDSWrcFEJDz3y9AO
thank you for your feedback.
The egress fee point is one that most teams underestimate. AWS, Azure, and GCP all quietly print money on free cross-region replication, and the bill compounds with every backup nobody looks at.
The Azure tier-change feature is honestly the part I'd use most. In my experience watching cloud bills, idle storage stuck in the Hot tier is one of the most common waste patterns. Most teams set it up once and never go back to clean it.
Curious, do users actually use the tier-change flow as much as the file transfer, or is it more of a "they discover it later" feature?
Azure tier changes came from my own need first. I had containers on Cold that should have been on Archive. I had custom Python scripts that I had to fine-tune for each task.
A few users who bought Blober for transfers then asked for exactly this, so it became a proper feature. It's a mix of people discovering it after buying and people who specifically wanted bulk tier management without scripting.
I'm planning to add more mutations, like AWS move to Glacier storage to save cost.
People set up a container, pick a tier, and never revisit it. Being able to select blobs visually and move them in one click makes it simpler to manage.
Really impressive build. Supporting GoPro Cloud and Google Photos is no small feat.
I’d focus on SEO for keywords like “transfer Google Photos to Backblaze B2” since that’s exactly what users search for.
Great product solving a real problem.
Thank you. SEO with those long-tail queries is my current focus actually. I've been publishing targeted articles at https://blober.io/kb/articles/ and they're starting to bring in organic traffic. Appreciate the suggestion.
The positioning I’d lean into is not “file transfer between cloud providers,” but non-custodial cloud portability.
The provider list is useful, but the sharper pain is: “I want to move or back up my cloud data without routing everything through another SaaS, storing credentials elsewhere, or paying per-GB transfer fees.”
For marketing, I’d test concrete migration stories: GoPro Cloud → Backblaze B2, Google Photos export alternative, S3 → R2/Wasabi without transfer fees, etc. Those feel much more searchable and urgent than the generic 11-provider message.
Curious how you handle resumability and verification for long-running transfers. For this kind of tool, “it won’t silently fail halfway through” might become one of the strongest trust signals.
"non-custodial cloud portability" is a good one, I might steal that...
You're right about the migration pain too. Articles like GoPro Cloud to Backblaze or Google Photos without Takeout perform way better than articles for other providers.
On resumability: transfers stream data in parallel, and if a stream fails, Blober retries it automatically a few times. It checks internet connectivity between retries so it's not just hammering a dead connection. If a file genuinely can't complete after retries, the task still finishes and users can see exactly which files failed. They can restart just the failed files without re-running the whole task. So it won't silently fail. You always know what made it and what didn't.
Local-first + one-time purchase is genuinely the right call for a file transfer tool — nobody wants a subscription for something that should just work. The Google Photos API change killing third-party access overnight is a perfect example of why routing through your own machine matters.
The marketing side you mentioned — I've been in the same boat as a solo builder. What's worked slightly better for me is posting the problem story (like this post) rather than the feature list. You're already doing it here. Keep that format.
Really appreciate the feedback. It's really good to see a personal problem can scale to other people with similar problem...
I'll keep posting and finding the right forums. Other than Indie Hackers, do you know any communities that are welcoming to solo builders sharing what they're working on? Reddit has been tough for me.
This is stronger than just a “file transfer app.” The local-first angle is the real wedge: no server relay, no credential storage, no transfer limits, and no subscription tax. That is a much sharper position than competing with generic cloud-sync tools.
I’d probably make the privacy/control story more central than the provider list. The list proves utility, but the trust claim is what makes Blober different: your files move between clouds without the product becoming the middleman.
One thing I’d think about early is whether the name Blober will age well if this becomes a broader local-first cloud operations tool. For a more serious cloud workflow/platform direction, Xevoa.com would carry the product cleaner than a name that sounds tied to “blob” storage only.
Thank you for the perspective on leading with the privacy/control angle over the provider list. That's something I've been shifting toward and it's good to hear it validated...
On the name, all good names are taken, including
Xevoa.com. But honestly I like the blob connotation. Blobs are essentially what files are in the cloud, so the name fits what the tool does.The name Blober has stuck with users. Renaming at this stage would cost more in brand recognition than it would gain. But thanks for the suggestion.
One practical thought on Blober.
Since the name seems intentional and users already connect it with cloud files, I would not push the rename point further.
But the positioning still feels worth tightening because the local-first privacy/control angle is probably the strongest reason someone would choose Blober over generic sync tools or CLI workflows.
If useful, I can do a focused naming/positioning audit around the current brand and landing page: what Blober currently signals, where the privacy/control story should lead, how to frame the trust claim, and whether the name/domain can support the broader local-first cloud operations direction.
Not a long consulting thing. Just a sharp written breakdown with practical recommendations.
I’m doing a few of these at $99 while refining the format. If useful, connect here and I can put together a clear outside read:
https://www.linkedin.com/in/aryan-y-0163b0278/
That’s fair.
If users already connect Blober with cloud files and the blob meaning is intentional, then keeping the name makes sense. No reason to force a rename if recognition is already forming.
I’d still lean hard into the privacy/control wedge in the messaging though. “Move files between clouds without your data passing through someone else’s servers” is much stronger than just “supports 11 providers.”
That trust angle is probably what separates Blober from generic sync tools and CLI alternatives.