[YS Learn] Blowhorn’s journey to onboarding 40,000 drivers in 4 years and ‘Uberising’ logistics

Every startup is built to solve a pressing problem. The issue could be consumer-facing or some urgent business need. For example, Ola and Uber saw a gap in the commute and transport segment. 

Similarly, for Blowhorn, it was logistics. 

The startup’s founders – Mithun Srivatsa and Nikhil Shivaprasad – realised in 2014 that though there was no dearth of truck drivers in the logistics sector, the industry lacked a common platform which could aggregate and bring together the fragmented market of mini trucks. 

Basing their model on cab aggregators Ola and Uber, the founders thought of replicating it for goods transport. Today, Blowhorn operates in major cities in India, with around 40,000 drivers on board. It has raised $8.8 million in equity funding and recently raised debt capital from Trifecta Capital. 

The company connects customers with intracity transportation providers to handle loads ranging from one gram to one tonne. Additionally, it provides fulfilment services and full API integrated delivery services. 

ALSO READ

[YS Learn] How WhiteHat Jr got its first cheque of $1.3M and how it found a $300M exit with BYJU’S

What problem does the product solve?

Blowhorn CTO Santosh Desai explains, 

“When building MVP, it is quintessential to have clarity on the problem at hand and not deviate from core features.” 

While the add-ons and value-adds are desirable, it makes sense to include them in the MVP (minimum viable product) only if development and testing costs are minimal. “Since we did not start with much capital and the founders had already bootstrapped the company, taking key business inputs on how the user journey should look like came from the founders themselves, who were ready to get their hands dirty,” he adds. 

He adds that in Blowhorn’s case, the advantage of having a software generalist helped to build the MVP quickly and efficiently, while testing it simultaneously without additional development/project management overheads. 

“Having a logistics supply chain and in-house technology expertise helped us, otherwise we would have had to minimise on the back-and-forth discussions with the software development companies. It's also a full-time job, a phase where undeterred focus (energy and time) is needed to get it right,” says Santosh. 

ALSO READ

[YS Learn] 10 reasons why things aren’t as chaotic as they seem to be

Build your MVP for the core drivers 

When Blowhorn was building the app-based booking for intracity logistics, the key market drivers or core features included the estimated time of arrival, real-time tracking, insight into trips without reaching out to a call centre (which was the norm back in August 2014). 

Santosh explained that they focused on building out an app for partners (who were semi-literate and were not used to smartphones). Thus, it was key to get the user interface right because the team believed in using GPS mobile Android data for real-time tracking rather than depending on telematics/GPS device. 

“We were also quick to realise that just having a web interface for customer bookings was not sufficient. So, we eventually added Android and iOS versions of the customer app. The ability to give hassle-free logistics service without having to talk to multiple people (via the app) helped us cut the costs as we did not have to rely on a call centre model,” says Santosh. 

Focus on simplicity 

For the customer app, the Blowhorn team kept it to simple goods movement from A to B. Slowly, they started adding functionalities such as rescheduling, multiple waypoints, and contacts of different customer-nominated SPOCs to facilitate fleet planning. 

“We need to keep looking at the user feedback, eliminate the noise, prioritise the features and be able to constantly assess the development and whether the vision we started with is addressed. On the driver app, we started adding more trip workflows for different kinds of journeys (loading, labour, etc), integrated navigation system with Google Maps, geofencing so that trip data is accurate, etc,” he adds.  

The team also realised that internally, Blowhorn also needed a robust system to ensure automation of driver payments, customer invoices, etc. This is a relatively easier phase compared to the MVP as one just needs to make course corrections and add new features.

Gather user feedback

Santosh explains that for any product from its MVP stages to growth, it is essential to capture user feedback. He adds that the order in which questions are posed also psychologically helps users to give prompt responses. 

“Randomising the feedback helped us with the right feedback on time. Once the product was out on the app store, we needed to start sorting out these teething issues as soon as possible. Internal apps for driver-partners and Blowhorn users’ portal sometimes underwent multiple deployments in a single day,” says Santosh. 

He explains many cases were underlooked and needed quick deployments to reassure the commitment of making the experience hassle-free (applicable to both internal and external users). 

“We always had a fallback option when rolling out new features (even if it is as basic as uploading the spreadsheet). Business continuity is important and technology robustness gives that confidence to the customers and Blowhorn users,” says Santosh. 

ALSO READ

[YS Learn] Moglix founder Rahul Garg on getting marquee investors like Ratan Tata, Accel on board during early days

Focus on core architecture 

After testing out the initial user base, Blowhorn rolled it out to newer cities, building confidence with a template for the full-stack technology platform. 

“If we have the right people who understand and share the vision of the company, the addition of features get simpler because we get the right feedback from the ground teams. However, the choice of technology and architecture principles are key,” says Santosh.  

These, according to Santosh, prescribe ease of maintenance and ensure the stack does not get bloated (or tech debts keep accumulating). Having a senior architect who oversees the development procedures early in the stage also helps.

“It is very important to get the technology stack right. The choice of the right language, framework and libraries are important so that tech hiring is simple. In an early-stage startup, it is imperative to get the architecture right in the first cut as every iteration/re-architecture quadruples the development cost,” says Santosh. 

It is also important to keep the code base simple and maintainable so that attrition does not come in the way of feature building. The architecture should be flexible to accommodate disparate modules with the right modelling and tools (like an event-based model or docker-based builds). 

Since time is limited, it makes it even more important to get it right the first time. This should be easy with banking on the advice of people who have built similar minimum latency and internet scalable systems. 

“It is easy to tell in theory what should be done and what should not, but the actual experience of every entrepreneur is unique. Staying humble, listening to the issues at hand and not over-engineering definitely helps. The product person should get into the shoes of the user for which the system is designed, and ensure that they are happy with the overall experience. Once the product has found the market fit, it’s just a scale problem (scale and promo),” he explains.