How I rode the Hungarian social network app goldrush wave (while it lasted)

Around 2009, the largest social network in Hungary was not (yet) Facebook, but a site called iWiW. At its peak, it had 4.5M active Hungarian users (from the total population of 10M in Hungary). When iWiW announced the opening of its app platform in 2009, I was among the first to develop apps. The two apps I built in 10 weeks were used by 1 million Hungarians - roughly every 6th person with access to the internet at the time.

Getting inspired from the Facebook app goldrush

While at university I spent a semester studying abroad in the US in 2007. Here I witnessed first hand just how successful the first batch of Facebook applications were. Students enrolling in the first Stanford Facebook Apps class created some Facebook apps used by millions of people. A few months later some actually sold their apps for a six-figure sum. Not a bad outcome for the time invested!

I missed the train with Facebook apps, never having written one, but was regardless fascinated by the success stories. However, 2 years later a unique opportunity came along to rejoin this apps wave. The largest Hungarian social network, iWiW announced the opening of its app platform, built on top of OpenSocial. I was determined to not miss this app goldrush opportunity - and got to work.

The opportunity seemed perfect: at this time Facebook was still struggling to get a grip on the Hungarian market, with less than 1M registered users. Meanwhile, iWiW had almost complete internet penetration in Hungary: out of the 6M connected Hungarians, 4M of them were registered and using the network regularly.

The killer app idea in 20 minutes: what worked well on Facebook?

Given the opportunity, the next question was: what exactly should I be developing? I didn't spend too much time with this question: I just went and checked what was already working on Facebook. As of 2009 the top 10 non-game apps on Facebook were these:

1. FunWall - messaging / wall
2. SuperWall - messaging / wall
3. Top Friends - dating
4. Are You Interested? - dating
5. Movies - movies
6. Pieces of Flair - messaging / wall
7. Zoosk - dating
8. iLike - music
9. SuperPoke - messaging / wall
10. Sparkey - dating

From the top 10 apps, 4 were on wall enhancements & messaging, 4 on dating, 1 on movies and 1 on music. I quickly went through which one of these would be easiest to develop. I chose a simple music app, and the enhanced wall ones as the best bang for buck ideas - and started coding an app for music playlists. I gave mine the very original Jukebox name (in Hungarian: Zene Doboz), and so the coding began.

Jukebox: 10 weeks of coding to make it to the top 3

The inspiration for building Jukebox came from the iLike app on Facebook. From the usage numbers and reviews, it was very obvious that people loved listening to their favorite songs, and discovering what their friends' liked.

iWiW adopted the Google OpenSocial API for developing applications. OpenSocial is pretty similar in its ideas to Facebook's app API. Via a Javascript wrapper the application can request a guid of the current user, and with this guid get profile information, information on friends, and also store a some very limited data. Whatever you could do with the Facebook app platform, you could also do it via OpenSoical. The real key to building a more feature rich application was to put a proper backend behind it to be able to store and serve much more rich data.

I built a pretty simple app, where people could search Youtube videos, add them to a playlist, and browse songs on their friends' playlist. The frontend was a plain HTML & Javascript application, and for the backend, I build a very basic CRUD component using PHP and MySQL. The backend part ran on a shared hosting instance on MediaTemple for $30/month. This is how the app looked like:

I got ready with the app just in time for the launch of the platform and was curious to see how well it would do. On launch day, there were about 50 applications launching on iWiW, and Jukebox rocketed to the #2 spot immediately. I had about 4,000 people using it per day - not having high expectations, I was pretty thrilled. Traffic was slowly picking up. Then, after 6 months, iWiW made a big change, making apps more visible on people's profile, and my traffic went x10 overnight:

The surge in traffic was great for traction - in a couple of months the app got to 650K installs -, however, it hit my backend really hard. Even before the traffic spike, I upgraded to a standalone MySQL container on MediaTemple, because the shared hosting one would time out frequently. However with the increased traffic, I kept running into issues with shared hosting and MySQL - and eventually migrated to Google App Engine. Back then, GAE was incredibly cheap - it came out even cheaper than using AWS, which was a bargain, given that it provided a PaaS solution. This was also my excuse for picking up Python - in 2010 GAE only supported this language, the Java version was only WIP.

Database repair during the ski trip

Initially, the Jukebox backend was served via MediaTemple shared hosting. It used a MySQL database with the default settings. Up to about 5,000 daily users and less than 5 req/sec, this setup worked fine. Then in January 2010, I was on a ski trip with my buddies. One morning I woke up with about a hundred email complaints about Jukebox being down. Turns out that with the sudden load in spike, the index of the MySQL database got corrupted, and the database was unusable from there.

I did not have a laptop on me for skiing (it was 2010!), so I ended up installing an SSH client to the machine in a netcafe, and remoting in the server. Turns out, the default MySQL engine MyIsam is pretty sensitive to table corruption in environments, where the mysqld process can be killed in the middle of a write. Which is what shared hosting might just do. To resume my skiing, I ran the REPAIR TABLE command, which fixed up the database, and the backend was back.

The same issue started happening a couple of times a week, so I looked into alternative solutions. First, I changed the MySQL engine to InnoDB, but the shared environment still was giving me issues. So I moved the database to FathomDB, who promised to seamlessly scale MySQL, by spinning up the right size Amazon instances behind the scenes. Except when I got spikes of load... the database server crashed every now and then while trying to scale up.

So with the "database as a service" not working out, I decided to give a PaaS solution a go. After some research and listening to my gut ("hey, it's Google! must be good."), I moved the whole backend to Google App Engine. Finally, GAE had no issues scaling up or down to handle the heavy traffic spikes. The only issue I had here was a couple of small outages, and a heavy data loss of half a day. Overall I was very pleased - finally I could focus on writing code, and let GAE deal with the infrastructure.

Super Wall: a messaging app with images & glitter

6 months into the launch of the iWiW app platform, my Jukebox app was the stable #2 app on the site. However, one type of app I did not see anyone build was a "wall with extras" kind of app. I looked back to my list of the most popular Facebook apps and realized that

From the top 10 apps, 4 were on wall enhancements & messaging, 4 on dating, 1 on movies and 1 on music.

Since no one else saw the opportunity in building a wall & messaging app, I decided I'll step up for this :)

The key reason that the top messaging / wall apps on Facebook got popular was that pictures - cute or cheeky ones - could be attached to messages. I quickly built a prototype where images could be uploaded, and those images were displayed together with the message. Just like with Jukebox, the backend initially also ran on a PHP / MySQL stack. I also added a few basic features, like browsing the most popular uploaded images, and embedding videos via Youtube... and in 2 months, the app was ready. I gave it the name Super Wall (Szuper Üzenőfal).

Before publishing, I had one more novel idea I wanted to add. Back in the '90s, glittery gifs were very much in style. I figured would it not be fun, to be able to add these retro, glittery filters to images? One of the popular open source libraries with built in effects like this was ImageMagick - which also comes with a PHP wrapper. It took a week or two of fiddling, but I added a few  different glitter effects that could be added to images uploaded. What started as a fun effect had a massive uptake: people would add this specific effect to every 5th uploaded image:

6 months after launch the app was installed by 450K people, rocketing the app to the #3 overall spot. On an average 30K people would open it, with special days like New Years' seeing surges of 4x, or about 120K people.

Just like in the case of the Jukebox app, the shared MySQL instance could not take the load - not even for a couple of days. The same way as with Jukebox, I also rewrote the backend in Python, and ported it to Google App Engine. GAE dealt with the spikes, including the New Years' surge really well.

The rise of Facebook, and decline of iWiW (and the iWiW apps)

Just like the Facebook app goldrush, the iWiW app goldrush window closed after some time. Interesting enough, both Jukebox and SuperWall saw the number of daily visitors decline dramatically because of different reasons.

Mid 2010 Facebook started to catch up, and slowly overtake iWiW for daily active users. The team at iWiW decided to try and turn things around, rolling out a massive redesign of the site. Part of the redesign meant making the apps less visible on people's profile page. When I saw the new design, I braced for a decrease in traffic, as many people listened to others' music on the other person's profile page. I was anticipating a 10-20% drop in traffic... but I was wrong. The actual traffic loss was about 60% as soon as the new design rolled out:

In all fairness, the redesign did not go down well with many users of the site, and only accelerated Facebook's market share increase:

Odd enough, however, while Jukebox traffic plummeted, SuperWall was doing ever so good right after the redesign. However, as iWiW itself kept loosing people to Facebook, the application's daily visitors also went down. By the time iWiW announced its closedown in 2014, it had less than 1,000 DAU - down from the previous 40K DAU.

What I learned from the iWiW app goldrush

Just like in the case of many other goldrushes, few people anticipated this specific goldrush to happen. In this specific case, very few developers realized there's "easy" ways to get significant traffic, with pretty simple apps. There were less than 500 apps developed in total for iWiW, and only 20 of those got more than 100,000 installs.

Did the success in gaining user traction translate to making a bunch of money as well? I did make an okay income by showing ads on the apps: the monthly revenue for the two apps were between $40-$1,400/month. (The reason for the low figure was that both the cost - as well as the revenue - from ads for the Hungarian market were much lower than they would have been e.g. in the US) However I did not get to keep much of this revenue: most of it went for paying GAE charges. The more people used the apps, the more ad revenue I got - and the more GAE charges I racked up. Overall ad revenues did cover GAE costs, but just about. However, what I did learn, is how to optimize GAE usage: especially when Google decides to raise prices through the roof, like they did so in 2011.

The main thing I did learn on this project was how truly difficult it is to build a backend that can actually serve 1 million real users. This was the first time I ever built anything used by more than a thousand or so people. I experienced all the pain of trying to server 500-1000 req/min on a single core MySQL machine. And then I was forced to teach myself how to export or import data to and from GAE, to keep the site running. There's very little substitute to figuring things out on your own. This project forced me to step out of my comfort zone, learn Python to use GAE, and dig deep on how MySQL and NoSQL databases worked under the hood.

Goldrushes - like the Facebook app goldrush, iPhone app goldrushes, or even this iWiW app goldrush - are all an amazing opportunity for us, developers to learn and build something new. If you join a goldrush early enough, you can only win: you'll be forced to be creative, learn new technologies, and could even make some money on the way.

And though many of the goldrushes have ended, a new goldrush is just starting right now. This is the Chatbot goldrush. Most developers will focus on the Facebook chatbot platform. There is, however, lots to win on the smaller platforms that opened up their chatbot APIs as well, like Kik, Skype and Telegram. There will be developers building creative things on top of this, and some might build experiences that millions use. What better excuse do you need to get coding?

Stats

(This article is also published in Hungarian on the popular Tech Inspiráció blog: Az iWiW app aranyláz meglovagolása )