How we cut SMS costs using Twitter Digits
Using phone numbers to register users is very useful for various reasons. First, the steps are simpler (1) enter your phone number (2)get a code through SMS (3)enter the code to log in. Users don’t have to leave the app which is the case of using emails for verification. It’s also easier typing numbers on mobile devices. As Digits sets to do, using phone numbers also eliminates passwords entirely making it not only easier for users to sign up for your app but also, difficult for hackers to impersonate (unless you give your phone out, which is outside the scope of security of an app).
However, there are challenges in taking this route, especially as a startup. First, you have to pay for every SMS sent, unlike emails. This ties your cost directly to the number of users of your app. And in some situations one user may be using different devices which further increases the cost. My previous startup Saya had this issue where we had to meet the growing user base at that time. The SMS cost projections were staggering in relation to the users we wanted to acquire. In fact, if you get lucky and users are signing up for your system you panic a bit because you know you are incurring SMS costs.
So recently working on Beep, that was one of the things we always wanted to avoid. More so, with Beep, we are bootstrapping, unlike Saya. And when bootstrapping any variable costs must be avoided if possible.
Our first attempt was to let the user send us SMS to authenticate their phone number. Basically, after a user enters her number, the server generates a code, pops up the SMS app on the phone, and pre-populate the content with the code. The user sends the SMS (with the code as content) to a specified number (or shortcode) which is then forwarded by the provider to our servers. We then proceed to authenticate the user. The idea was to shift the cost to the user, at least till we raise some money or become profitable. However, we still had a bad feeling about it and as we found out later, we had to pay to receive SMS too. Not good.
First of all, users are used to apps sending them code. Whatsapp, Viber, etc. almost all social mobile apps that you register with a phone number do that. Sending SMS before you can use an app is not convenient.
Second, the user onboarding was messed up. This was going to directly impact the signups and the conversion rate. If the user is registering for Beep on and iPod or other devices that can’t send SMS (some people use their smartphones over wifi and have no sim) then the user will have to send the SMS from the phone that has the SIM with the number used during registration. Ugggh. Cumbersome. You don’t want people to have such an impression about your app. Never.
So the user experience was messed up.
Third, it's operationally difficult and difficult to scale. We had to find a provider who can receive SMS from different users in different countries. Finding the provider is challenging. Finding a reliable provider, that’s even more challenging. It’s of no use if those users who are kind enough to send the SMS can’t even get through to use the service. We used Twilio for experimentation. It worked great. However, it turns out we have to pay to receive SMS, which defeated the whole purpose of eliminating that cost. I remember our time at Saya, we had to have about five providers just in case one of them is down. It’s not something that makes a startup guy happy at all.
So what did we do? After stressing over the SMS issue for a while. I gave up. We figured the ‘it’s not a problem till it’s a problem approach’. Thing is, it was taking time away from building the actual app. And also, hopefully, we may land some money later which can take care of that. So I moved on with developing the actual app. For testing purposes, signups weren’t getting authenticated, so as privacy protection we weren’t providing message history for reinstalls.
It was still a bother. The user experience on Beep is only great and useful if you have a critical user base which means users find a number of friends when they signup. At the same time, we had to provide privacy and security, such that you can’t just enter anybody’s number and start seeing what the person is doing on the service. Our success, to a large extent, depended on how we overcome this challenge. We even explored using WhatsApp to send the activation code. I had sleepless nights, till we finally discovered Digits!
In short, for a developer, Digits helps remove the boilerplate phone SMS authentication that can be found in most social/mobile apps these days. For startups this is a big relief as it allows you to focus more on building your app and more importantly, it saves you money! Just watch the keynote video.
I have been using Crashlytics for a while. I got emails about Twitter’s Flight conference that happened in October. After the conference, I read about Fabric and the new set of tool twitter is providing for developers. I didn’t really pay attention.
I sent this email to Kweku and Omar when I first saw digits.
The conversation didn’t go far. My first impression was that this is another OAuth over SMS. This means the user must be a twitter user, but then not all of our target users are on twitter. Boy, I was wrong!! It’s not a freaking OAuth. Ok, It has OAuth parts. But not like Facebook Connect or Google+ SignIn whereby the user must already be a user of the platform. Digits doesn’t require that your users be twitter users. It’s a separate platform, just for phone authentication. And if you want twitter integration, it’s even simpler because it’s part of the Fabric toolkit!
Dec 3, Omar sent me this.
I watched the video, and I couldn’t believe it! It’s available and independent of the Twitter platform which means it meets our needs perfectly. Even better it’s available in 191 countries! Yep, growth simplified. I upgraded Crashlytics to Fabric and integrated digits into our iOS app the following day! I was so excited I just wanted to see if it’s real and bam it worked just perfect.
I have also integrated it into our Android client and it works perfectly.
Our team is so excited about this timely intervention from Twitter. This is going to save us a lot of cash and we can confidently grow without the fear of additional costs as our user base increases. We also feel having Twitter in our system gives users some level of reliability which is good for the app.
Preliminary tests show SMS is delivered within 5 sec. Sometimes 2 sec. We haven’t done testing on a massive scale yet so we don’t have data on rate limit from Digits yet. But so far we are happy with using Digits. Thank you, Twitter for such an investment.