Mobile App Delivery

Last week I was working on a micro web application to deliver a mobile app via SMS.

Upon hitting the landing page, the user would sign up with his/her name, email address and mobile device type. We would temporarily store their device type at this point while waiting for the user to either enter their mobile number to receive the SMS on the next page.

The user can choose not to enter their number and click on a link to get to their respective app store if they are already on their device, or on the web if they are using their desktop.

If the user has entered their mobile number, we would send them a SMS with a customised link, for example, http://startup.com/ios/ for iOS users, to redirect them to their app store when they pick up their device.


With this new system, we saw an increase in conversion rates. I would attribute that to both the new design of the landing page as well as the easier onboarding process. The new user experience was so smooth that about 70% of users who signed up, entered their phone number!

This method of distribution is not novel, a bunch of other businesses do it too. We found that it is especially useful for mobile apps that do not get discovered on the mobile device itself. As we reduced the friction from discovery to acquisition, users do not need to navigate through the app store themselves and are more likely to go from signing up on your website to downloading the app.

Engineering

As the web application was for an early stage startup, they had no existing web infrastructure and deployment tools. A full stack effort was required to launch and set up a cloud server, write the web app, choose a deployment tool and made sure it was ready for production.

Firing up a server was pretty easy with Azure. Microsoft provided us with credits from their Bizspark initiative, so we used them for infrastructure. Setting up the server was easy enough from a technical point of view.

After a quick round of discussions, I decided to go with the Nginx and Passenger combo, Ruby as the server side programming language and Sinatra as the web framework. For the prototype, I chose to run with a simple Sqlite3 database. However, in production, we hooked it up to a SQL Server hosted on the same Azure platform.

Needless to say, I used git for version control and Capistrano to manage deployments. The entire set up was pretty slick and I could deploy a build with one command. To ensure I had the same environment locally, I developed in a VirtualBox instance managed by Vagrant.

This project had a hard launch deadline. Given more time I would have added continuous integration to test builds and deploy them as soon as they are ready.

All that fanciness was required for future proofing and maintainability.