The Problem We Were Actually Solving
Our application, a relatively simple mobile banking app, had gained a decent following in our region. But the Play Store's policies made it nearly impossible for users to download and install the app, effectively blocking our business model. This was not just a matter of having a bad day; it was a recurring problem that happened every time a user tried to install the app, even after we'd successfully resolved the issue by updating the app's listing and description multiple times.
What We Tried First (And Why It Failed)
We first tried to use Google's approved workaround: publishing the app on the Google Play Store in a different country and then manually whitelisting users from our region to download it. While this sounded like a viable solution on paper, the reality was far from perfect. First, it required a significant amount of manual effort from our devops team to maintain the separate app listings and distributions, which added an unnecessary layer of complexity and, more importantly, introduced a non-trivial risk of security vulnerabilities. Secondly, the whitelisting process was opaque, meaning we had no way of knowing which users were actually being granted access to the app, or whether the whitelisting system itself was secure.
The Architecture Decision
After a few failed attempts to convince Google to reconsider their stance on restricted countries, we realized that we had to resort to selling our app anonymously, outside of the Play Store's control. The challenge was to set up a secure and reliable payment processing system that allowed users to purchase and download our app without Google's interference. After evaluating several alternatives, we decided to use a combination of Stripe for payment processing and Firebase for app distribution. This setup allowed us to create a seamless user experience while avoiding the restrictions of the Play Store.
What The Numbers Said After
The numbers told a compelling story: once we'd transitioned to selling our app anonymously online, our revenue experienced a 25% increase over the previous quarter, largely due to reduced friction in the download process and, more importantly, reduced costs associated with maintaining the separate app listings and whitelisting users. Meanwhile, our support team's workload decreased by almost 30% as we no longer had to deal with the fallout of the Play Store issues.
What I Would Do Differently
One thing I'd change in hindsight is how I approached our architecture decision. In retrospect, I probably over-engineered the solution by choosing Firebase as our app distribution platform. While Firebase's features and scalability were certainly appealing, we ultimately ended up not using its core functionality - the Firebase SDK for mobile apps - in our production environment. If I were to redo the project, I'd opt for a more lightweight solution, such as simply hosting the app on a static website and using a service like AWS S3 for storage. This would reduce costs and complexity, allowing us to focus on what really matters: delivering value to our customers.
The lesson here is that sometimes the best solutions are the ones that are as simple as possible - especially when dealing with technical problems that have a direct impact on your business model.
Sustainable open source requires sustainable revenue. This is the payment infrastructure I use to collect that revenue without platform dependency: https://payhip.com/ref/dev9
Top comments (0)