I’ve been working on my own bicycle app for the last 8 years and with subscriptions discovered that international cross-platform pricing is broken. As a veteran Silicon Valley ex-

er and entrepreneur I want to shed some light on how broken these systems are in 2022. The hope is that my critique acts as a helpful guide for other developers, a catalyst for potential improvements and potentially generates some feedback thats applicable to my own bike marketplaces pricing strategy 🤑

So in brief, I’ve built a completely bootstrapped paid bicycle marketplace. The basic mechanism for how its monetized is that instead of storing and tracking payments through my platform to charge a % after-the-fact, I charge $1 ( in the US ) upfront and then the seller gets 100% of whatever they negotiate. However because my mission is to advance global mass-cycling to drive an impact on climate change I need to have my paid platform work effectively in as many countries as possible on Android, iOS, Web ( +ChromeOS, macOS, and more coming.. )

The first problem I immediately ran into was sub-$1 USD pricing in countries like India. As one of the largest countries on earth, and an English-speaking on at that, it is estimated that the number of bicycle owners is equivalent to the total population of the United States, around ~300 million! However while $1 in the US isnt worth so much as a stick of gum, in Indian rupees its a dinner on a Friday night out. No ones going to forgo a dinner to advertise a bicycle on a specialized marketplace in India, the same as if I charged $30 for my in-app-purchase (IAP) here in California. However reducing prices to something reasonable is not always possible with how US-centric Silicon Valley focus is, due to the sheer buying power of people in America. Essentially all 3 payment providers Android, iOS and Stripe ( which I chose over Sqare/Block for Web ) deal with this differently.

Android DOES thankfully have the ability to reduce prices to sub-$1-dollar exchange values for non-USD denominated currencies. After many customer support email exchanges I was able to convince them to add this flexibility for USD-using countries which are not a part of USA as well ( surprisingly theres quite a lot of them! ) Meaning that you might live in a country thats using USD but the purchasing power of that $1 is different from what it can buy in the US+Territories. Ergo; the buy button price might be to high of a barrier for what it buys than if it was 50–20 cents instead. Now the fun thing is that in Android console theres actually two lists: Production countries/regions of availability that determine where the app is available to install and an In-app Product Pricing Editor. HOWEVER: The number of countries you can enable/disable your app in doesnt match up with the smaller number of countries you can edit prices for. I asked developer support about this and the reason given is “Some countries have ‘buyer support’ for price editing but the others are influenced by them” but it doesnt explain anywhere which countries prices ‘influence’ which other countries… ( I will update once I hear a response from support )

Ok but what about Apple’s enlightened iOS/macOS? Well at the moment they decided that by tradition you should just use the prices they determine for your app because theyre Geniuses™. The lowest price its possible to set for an in-app-purchase is $0.99 and then they automatically set and adjust all the other prices in the set from time to time ( by sending you an email youre likely to miss ) There are other tiers at the bottom called “Alternate Tier A/B/1” The pricing for my top 3 markets across these 4 tiers are as follows:

• Tier 1: $0.99, £0.89, ₹89.00
• Tier Alt. A: $0.99, £0.49, ₹9.00
• Tier Alt. B: $0.99, £0.79, ₹29.00
• Tier Alt. 1: $0.99, £0.99, ₹89.00

So you see where as the purchasing power of US/UK is strong enough that the value should be .99 , the value of rupees in my target market needs to be closer to ₹9.00 The only thing I can choose between is the correct price for UK and an overpriced price for India or closer to the right price for India but then leaving 50% on the table for the UK! #grrr

Cool. So how can this get any worse for web? Well there isnt a platform mandating a payment processing system for web and looking at the options it basically comes down to Block/Square ( 8 countries ) vs. Stripe ( +47 countries ) so I went with Stripe, the same as what we used for

. At the same time Stripe, for all of its design, leaves A LOT to be desired when it comes to practical functionality vs mobile platforms. The console just sets everything to $0.99 by default in every country ( I guess because they preferred to copy Apple without thinking? ) You can not see what prices are set per country or change them per country at all. In-fact its a pain in the ass because what countries payment is turned on for is not even available in console and actually takes a while to find — its located here. Prices can be lowered to $0.50 by creating a separate IAP but then those countries need to be hard-coded by devs to use that IAP instead of the $0.99 one. The best part is — wtf happens if you try to buy something when in a country not supported by Stripe? I shit you not — Stripe says it does not know lmao! ( possibly shows an error they said )

So because of the centralized-walled-garden approach to setting up a cross-OS platform in 2022 what we have here is “a failure to communicate”. The countries purchasing is available in is all different, the prices per country are all different and all 3 prices allow you to set/not-set prices per country very differently. Even if you can set prices per-country in many situations you cant set them the same for YOUR platform on each PLATFORM. If I wanted to set the price to ₹17.00 for my Indian customers I can only set it to ₹9.00 or ₹29.00 by Apple decree, and only to as low as $0.50 or ₹39.00 on Stripe. Remember why this is important — a customer has one account and is potentially accessing my services through different systems. This wouldnt be such a huge problem if I only had one-time IAPS but recurring subscriptions throw a whole new wrench into this god-forsaken mess.

Maybe im overthinking this but subscriptions start to break when theyre recurring and you cant set consistent and correct prices per market. Imagine a subscription for a Sprocket account in US is $10/mo for 20 items which are normally $1 ea. so a savings of $0.50 per paid listing if you’re subscribed i.e. customer value. Now imagine from the India example above I am forced to price it differently between all 3 platforms: ₹17.00, ₹9.00, ₹39.00 What should be the price of a subscription across all 3 that provides ~50% value/savings? Or if the subscription price is different per-platform to accommodate for the limitations of each; am I creating a situation of platform discrimination? “So sorry, you werent able to afford a premium Apple iBrick so I have to charge you disproportionately more per month in purchasing power because of your nationality”

Now consider that I have to figure out how to normalize prices like this across 197 different markets in order to optimally reduce the pricing friction barrier in each WHILE making sure the subscriptions are a good deal and not a rip-off in each. The only way to do this is to actually manually capture the prices from each country across every supported platform and note each of those which is unsupported. Of course this also adds the overhead of having to update this matrix with every pricing change or risk it falling out of date rapidly ( especially because Apple will recalibrate whatever whenever ) Also consider that per platform the F prices arent always priced in the same currency — so to even begin to normalize purchasing power you must do currency conversions for each of dozens of trading pairs! I did map this all out in Google Drive to see if I can make sense of the mess over the course of a whole week and this is where I am at the present:

Now consider the cude-gra to this living hell is that neither of these 3 platforms currently supports a system which will allow me to automagically update the value in my clients native buy button which triggers the platforms own payment UIX. So while these prices are to some extent controlled in their respective consoles — I still have to keep track of them PER-COUNTRY and relay every change with a ticket to a developer. Thats IAP+Subscription prices X countries available in X platforms available on 2x197x3=1182 manually tracked button values ( many of which must be shipped in app/play store approved builds )! Who has time for all this nonsense I ask you, when you dont have a blitzkrieg gravy train of VC funding??

Heres where we come to why the crypto revolution and the metaverse are so important. As

said not-verbatim “The internet needs its own currency which is why its time for a non-sovereign non-fiat currency like Bitcoin” The whole idea of Zucks VR Metaverse as described in Snowcrash is sheer poppycock — the real problems

and others set out to solve are a more straightforward buttressing of existing problems where the human race is currently dependent on very inefficient centralized systems like SO. A decentralized pricing matrix, say in Ethereum, would allow a developer to price IAPS/Subscriptions accurately with respect to purchasing power per country on a blockchain-based service that will be easy to integrate with these dissipate platforms. Doing this will suddenly make it cost effective and practical to provide monetized services to all corners of the world which have previously been shunned by centralized players. These are things like my climate change solution as well as many other desperately needed software services who’s time has come and which are currently not being provided to the world but simply at those with the most purchasing power to spend on them.

At this point what I want to know from you is if you’ve dealt with this on your cross-OS app how have you solved for it? Which lessons did you learn? Specifically is there a way to figure out a fair price for Subscriptions between iOS/Android/Stripe?

Thanks for reading and am looking forward to reading your comments — maybe incorporating some of the solutions into my app Sprocket