When Tootle started, there were four of us. At the time, we were working on EdCrayon (Three60’s Education and Classroom Management System). The development of EdCrayon was pretty much complete and one of the better schools in town had been implementing it for a year. We were busy with building fewer last minute requirements such as Nepalese school standard digital report cards and student ranking systems. After those were done and the academic session ended, we were preparing for the next academic session and we were also in talks with several schools for implementation of EdCrayon.
However, because of earthquake of 2015, the school that were lined up decided to back out and use their EdCrayon allocated resources on repairing the infrastructure damages. We would come to work and not feel productive at all. Due to the sheer boredom at work, we started researching on several ideas including location based services. One of the very first ideas was to create an app that would allow users to track location of Sajha buses on Google Maps so that they could plan on leaving offices/homes by referencing estimated time of arrival provided by the app. Even though Sajha buses were comparatively convenient, the problem was that people had to wait for the buses, generally up to half an hour, since bus stops arrival timings were more or less random. We developed the prototype for a Sajha bus route but since Sajha bus did not show any interest we decided to move on to other ideas.
Sabaiko Sajha (Prototype)
Meanwhile, I was researching on asynchronous API calls for a pet project of mine. I had been trying to figure out the best way to sync client’s on-device offline database and off-device master database. In this process, one of the first things that I did was to look into creating my own implementation by syncing Android SQLite database with MySQL database. Up until this point, when ever client sync was required, I would simply clear out the content adapter’s list, remove all elements, get all elements from master server and refill the adapter. This allowed for easy implementation. However, even if nothing was changed in the client database, whenever the client hit the sync button or pulled to refresh, the process would get repeated. Basically the question I was trying to answer was,
“Is it faster and less expensive to individually assess for updates by comparing updated_date and id or to simply truncate and refill?” During the research for this, I stumbled upon newer technologies that would allow setting up changes listeners on client’s devices to refresh the changed list without having to trigger an action to sync the data. Using this finding and our research from location based services, we felt comfortable tackling the idea for a ride sharing application from a technological perspective, and Tootle was born.
Tootle was not Tootle from the very beginning. We continued our research on appropriate Business Models, Brand Positioning, Business Strategy, and Marketing and Delivery. Based on the changes in how we were going to position our brand in the market, we changed the product name from CabIO (digital cabs), KAR.ma (share your ride for karma), Bzuli (environmentally conscious ride sharing) and finally to Tootle (a fun way to travel without restricting the service to electric vehicles and only four wheeled vehicles). In the meantime, based on the Business Models and Brand Positioning, several elements of the app were also changed.
Bzuli and CabIO (Prototypes)
Although the concept of ride sharing is not new, and several companies such as Uber, Lyft, Ola and Go-Jek have implemented it tremendously well, Tootle is different mainly due to three core elements. First of all, we let our partners decide if they want to take a ride, i.e, we introduced the idea of casual Tootle partners. For example, a partner A can decide to give rides throughout the day and make this his/her full time job or simply give rides that matches his/her travel itinerary. The technology is adjusted in such a way that a tootle ride requests are sent to several partners within a vicinity rather than just one partner. Unlike aforementioned companies, there are no penalties involved for not taking a ride. Secondly, albeit not completely by choice, we have realized that frugality invites creativity. At every step of technology development, we have had to strategize inexpensive yet effective ways to solve problems. Although we are still purely in development phase as of today, I believe we can really take pride in what we have accomplished given the resources. This is also reflective in the product. We were forced to think about minimizing data consumption (given the high data cost in Nepal) and poor internet infrastructure. Currently, on average, a particular ride for a partner in terms of data exhausts 1 MB while him/her being able to log in, select appropriate ride, complete the ride and get paid, while the backend collects ride information such as timestamps for actions and exact route followed. This costs him/her 50 Paisa which is approximately $0.005. Finally, last but not the least, the major difference comes in the form of technology adaptation, contextualization and more importantly, communication. Kathmandu is traditionally more or less a close-knit community where people prefer talking to people to garner a sense of confirmation and safely. Therefore, it was crucial to build a simple and clean UI that gets the job done and focus massively on developing technologies that provided real time ride statistics to our team at call center so that they could assist people giving and taking Tootle rides. Similarly, since digitization of payment was essential but Nepal is not ready for secure and realtime credit card transaction, apart from local third party digital wallet integration we also have QR top-ups. To summarize, although from the surface, Tootle is a ride sharing application like Uber, it has established its own identity via contextualization of the requirements of Nepali needs. This is apparent throughout the technology.
From our experience, we have realized that market drives technology and not the other way around. We have also realized that although technology is merely a facilitator, it can do wonders to solve problems and invoke habit changes if done correctly. Now, we have a multidisciplinary team of 15 striving to make Tootle technologies and services better each passing day with the goal of doing it correctly.
Note from the author: This post is meant to be an ice-breaker for technology in Tootle. Please follow the blog for future posts that will discuss individual technology features, used technology stacks and all things technology.