Why I Built Buildsdrop: An App Distribution Tool That Doesn't Get in Your Way

If you've ever shipped a mobile app to a client, tester, or QA team, you've probably used Diawi. It's been the default answer to "how do I get this APK/IPA onto someone's phone without going through the App Store or Play Store" for years. I used it too — for a long time, actually — until the friction started outweighing the convenience.

So I built Buildsdrop.

This post is about why, not just a "look what I made" post. I want to walk through the actual pain points that pushed me to build my own infra for something that sounds, on paper, like a solved problem.

The problem with the status quo

I lead a mobile engineering team, and app distribution to internal stakeholders and testers is a weekly, sometimes daily, task. A few things kept bothering me about the existing tools:

1. Links expire, and not on my terms.
   Free-tier link expiry is fine in theory, but when a client opens a QR code three days after you sent it and gets a dead link, that's now your problem, not the tool's. I wanted expiry to be a setting I control, not something baked in to nudge me toward a paid plan.

2. No sense of a "project."
   Every build I uploaded was a one-off. If I had ten builds of the same app across two weeks, there was no grouping, no history, no way to look back at what I shipped when. For a team shipping iterative builds to QA, that's a real gap — you end up building your own spreadsheet of links on the side, which is absurd.

3. Ads and clutter on the download page.
   The page a tester lands on to install your build is part of your product experience, especially when it's a client-facing beta. A cluttered, ad-heavy download page undercuts that.

4. No visibility into what happened after you hit "share."
   Did the tester actually download it? Did the QR code even get scanned? For internal releases this matters more than people think — especially when you're trying to figure out why a bug report isn't coming in.

None of these are exotic asks. They're the kind of thing you'd expect from a tool built in 2024+ rather than one that's been coasting on being "the free Diawi alternative" for years.

What I actually built

Buildsdrop is an APK/IPA distribution platform: upload a build, get a shareable link and QR code, testers install directly. That part is table stakes — it has to match Diawi on the basics or there's no point.

Where I focused my energy was everything around that core loop:

Project-based organization — builds are grouped, versioned, and browsable, not just a flat list of expiring links.
Clean, ad-free download pages — because the install page is still part of your app's first impression.
QR-first sharing — since most real-world distribution now happens via someone scanning a code off a laptop screen or a Slack message on their phone.
Predictable link lifecycle — you decide when a build goes away, not a pricing tier.

Who this is for

Honestly — teams like the one I lead. Mobile engineers who need to hand a build to a PM, a client, or a QA tester multiple times a week and want that to be boring and fast, not a small ceremony every time.

If you've felt any of the friction above, give Buildsdrop a try. It's early, it's opinionated, and it's built by someone who was annoyed enough by the alternative to spend weekends on Docker configs instead of just filing a feature request into the void.

I'd genuinely like feedback from other mobile devs on what's missing — drop a comment or reach out.