Do taxis go south of the river?

Recently we’ve been engaged by AddApps to help with their start-up LDNTaxiApp.

What’s the app?

LDNTaxiApp is a mobile app that matches London’s Black Cabs with Londoners needing to go places. The idea is that you open the app on your mobile, hail a cab and one will magically arrive. Here are a few screenshots.

The app is in the app store and has been in production use for around 3 months with thousands of completed journeys.

Prototype to production

Our initial engagement was to add some new features to an existing Rails application and to work with Rob, the lead iPhone developer, to hook everything up to the iPhone. We worked to a fast release schedule building out infrastructure along the way. Within a couple of weeks we had availability of taxis, order fulfilment and push notification messaging done.

Some libraries that really helped us were resque_scheduler that supported an order being swept after a period of time, apn_sender for Apple Push Notifications and geokit-rails for all of the geo-location calculations.

Testing in the field

At pebble we write automated tests for features but we weren’t able to test in the field. Some things we learned were:

It is a much harder space to test effectively than a classic web app.

Building views onto the data

The team at LDNTaxiApp are amazing at listening to and contacting customers. They wanted an administration app to be able to have a view onto what was going on, how to identify problems in the process and make better decisions about the direction of the app. For us the application really came alive when we added a realtime map of the taxis available in London. As a Londoner this is fascinating. Where are the most taxis? Where do they typically go? What time of the day is most busy? This of course is all valuable data that LDNTaxiApp is building up. We could see pretty quickly though that the adage that taxis don’t go south of the river is true.

Start-ups need pragmatism

Apple’s approval process is long and frustrating. Finding a bug in your iPhone client means that it is likely that your customers will continue to find the bug for two weeks before it goes through the approval process. For that reason where possible fixes were applied to the Rails application. From a software engineering point of view this is clearly a bad decision but in a business context is totally understandable.

Working with an existing technology stack there were areas we could see that real improvements could be made. For example reducing the reliance on MySQL for short lived data like locations and moving it to a in-memory store like Redis or MongoDB. With the requirement for near real-time data we also talked about moving the API to something like Erlang or node.js.

This is all very well if you have millions of pounds of funding but in our case we had a limited budget and an app in production use that worked well. Pragmatism was the order of the day here and the realisation that for a start-up perfect technology is not as important as getting to market. Just one of the things we learned from the client.

What went well

The project was a strong success in terms of following an Agile process. Effectively we were pair programming with Rob who was developing the iPhone app in parallel. On the few days we were not able to be physically located together fewer features were completed. Sharing knowledge between developers was key. Releasing quickly to the development server meant we could respond quickly to changes on both sides.

The application held up well to being featured in the Evening Standard and the Sunday Times according to New Relic the database and application servers are returning good response times with high customer satisfaction rates.

Tags

Can you help make this article better? You can edit it here and send me a pull request.

See Also