One Month to 4 Million Users & Cash-Flow Positive: The Pokecrew Story
Pokecrew is a crowd-sourced Pokémon GO map. It helps people find the Pokémon they’re trying to catch.
I shipped it on July 14th, and to date over 4 million people have used it — mostly in South America. It’s doing $100–200/day right now in ad revenue from AdMob.
On July 11th, I texted my friend Lucy that we should build something for Pokémon GO. Everyone was playing Pokémon GO and everyone was talking about Pokémon GO.
She immediately suggested a map to find Pokémon — and she designed it that evening.
The idea isn’t technically complicated — it’s just a lot of pins on a map. Plenty of apps have pins on a map. Easy to build encourages competition, which makes moving fast and being early to market important (and eventually having a moat).
I didn’t really sleep for 3 days. I stopped showering, exercising — every little thing I could do to maximize time spent coding.
Pokecrew went live on July 14th with a post on Product Hunt.
73,774 people used it on the 1st day. Or, tried to.
The site wasn’t loading from the traffic. It felt like I was disappointing thousands of people at once.
The most important non-technical thing I learned about scaling from Pokecrew is to spend the least necessary amount of time on it. It’s a trade-off, sure — but it’s the correct trade-off, and here’s why:
To engineers, scaling is sexy. Making small changes can improve performance by orders of magnitude — and understanding what those changes are is a difficult problem that feels good to solve.
This is a trap.
Your users don’t care about how performant your website is. They don’t care about your engineering prowess. They only care that the products works and is fast enough for them.
At every step, I scaled to only the minimum necessary for the site to continue. An index on latitude, longitude and using BETWEEN (in SQL) to get the sightings for a bounding box was fine for 500,000 Pokémon sightings. Using PostGIS with an index was fine until 10,000,000 sightings. Separate queries for big bounding boxes and smaller bounding boxes is doing fine for now (~50,000,000 sightings).
Scaling Pokecrew is an ongoing effort, but it won’t grow the product — it‘s just keeping the lights on. Building new stuff for users grows the product, and the engineering time spent on scaling takes away from that.
I’m glad that the site barely worked on the first day. If I spent the time scaling it to support the current load before shipping it, there’s no way 4 million people would ever have used Pokecrew.
Growth stops — and starts anew
A million people used Pokecrew in it’s first week.
Then, traffic went down.
July 29th was Pokecrew’s worst day. 62,154 people used it with an average session length of 3:13.
Google Analytic’s cohort analysis showed that only ~10% of users ever came back — and less than one percent used it 6 days later.
I didn’t know what to do.
So I tried a bunch of stuff:
- Made the map load faster on Android and iOS.
- Made it show more Pokémon sightings
- Fixed a bunch of bugs in the site
- Made the initial pageload faster
To be honest, none of those things really did anything.
I basically got really lucky.
Pokémon GO launched in South America
…and overnight, pretty much the entire active userbase switched to South America.
A bunch of Latin American newspapers ended up writing about Pokecrew
..and several more.
None of that helps retention though. Getting press doesn’t mean getting users that stay. It’s a temporary boost, and the only users from press that matter are the ones that continue using the product when the press inevitably dies down.
iOS and Android
The Latin American press was temporary — but I did notice one thing. 2/3 of people who use Pokecrew use it on their phone. Yet, it was a website.
It was a website that took a long time to load.
It was unusably slow on a number of Android phones (in older versions of Chrome, it didn’t even load).
You had to remember the URL to get back to it.
Getting your current location from the browser was flaky…at best.
The most successful Pokémon GO maps were native iOS and Android apps. And, more kept springing up. This proved nobody won yet — and Pokémon GO is a worldwide phenomenon. Even if one app is winning in the US, someone different can win in France, Spain, Chile, Argentina, etc.
The problem was…I’m one guy. How can one guy build native iOS and Android apps fast enough? I’d have to build everything twice, using a platform I knew little about (Android) and using a platform I hadn’t seriously built anything with in years (iOS).
By the time I could ship, traffic in the website would die down and the competitors would be far ahead of me.
I needed a way to work around that — and fast, or Pokecrew would die.
React Native to the rescue
So I did that. I didn’t really sleep, and I shipped the native iOS app within a few days.
The result was underwhelming, at first.
But, there was one key difference between the web and iOS app.
Google Analytic’s cohort analysis showed that ~44% of users came back — a ~30% increase in retention.
- Turned on AdMob ads
- Forced everyone on iOS looking at the website to use the app
- Finally got into the Play Store
- Forced everyone on Android looking at the website to use the app
Now, the daily active chart looks like this:
Last week, the mobile app grew +172%.
If this trend doesn’t change a lot, the traffic costs for the month are covered.
Since that’s the only recurring cost, that means Pokecrew is a cash-flow positive “business” (server spend is ~$1200/month right now)
Pokecrew has been really fun and I’ve learned a lot from this. I don’t see myself working on this for years, but it’s been fun so far.