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:

• 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.
• 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.
• 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.
• 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.