Building Haulio Zero: What We Learnt Expanding Overseas
In this article, we look at how Haulio has evolved over the years, and why we needed to rebuild our software architecture into one that is scalable and customisable for our growing needs. Based on multitenancy, multiple customers or “tenants” share the same resources while being able to configure the application to fit their needs. Shared resources make entry cost low and scalability easier and faster to apply.
Haulio’s Evolution
Haulio has come a long way since we first started in May 2017.
Initially, Haulio operated as an on-demand model to serve PSA’s Inter-Terminal Transfers (ITT) jobs. Hauliers simply needed to register their drivers and vehicles on the platform in order to take on shifting jobs within PSA’s terminals. With ITT jobs, hauliers can optimize their fleet’s schedule by utilizing their free trucks, which also serves as a reliable and additional source of income. Furthermore, these jobs are completed within the port, hence drivers are not required to travel long distances.
In 2018, a haulier asked for help for their overflow jobs – to reach out to our then 30-over haulier network. Back then, subletting a job to others was usually done over the phone, and were largely based on the relationships the hauliers had. With Haulio, hauliers could easily sublet their jobs to others, yet maintain the fulfilment they had committed to their customers. Subsequently, we took on empty container repositioning jobs as well, which refers to the shifting of empty containers between depots.
Since Feb 2020, Haulio has also successfully launched in Thailand through our collaboration with ESCO (Eastern Sea Laem Chabang Terminal Company limited), in a joint venture between PSA and Marubeni and Kamigumi of Japan. ESCO operates a terminal in Laem Chabang Port as well as an inland container depot at Lat Krabang, and has a vendor fleet of about 200 trucks and drivers. Haulio provides a digital vendor management tool for ESCO to handle and monitor their vast haulage vendors’ fleet.
The Need for Change
As Haulio scaled and grew, it became apparent that our existing software architecture needed to adapt as well.
The key push factor to build Haulio Zero was our overseas expansion – although haulage is crucial everywhere, each country has unique processes that require specific customisations. In fact, different states and provinces in the same country, even ports within the states, may have unique processes.
For example, in Singapore, hauliers usually only needed to deal with 1 or 2 ports (PSA and Jurong Port), utilizing a mostly standard process. However overseas, there can exist several ports managed by different operators (which can also be government or privately owned). As opposed to Singapore, a single container may interface with several ports, each with unique processes that needed to be considered.
In other countries, it is also common for trucking companies to have an average fleet size ten times that of Singapore’s. In Singapore, the average fleet size is approximately 10, with an average haulier trucking about 1000 containers a month. In Thailand, for example, the hauliers’ fleet size is easily in three digits, and at the same time, their customers can transact ten times the volume.
Haulage processes, though principally similar, can be quite different depending on locales, terminals, terminals and even customers. Typically, it is expected that a haulier would have had all the information required to complete the job, such as the booking reference number, vessel details, container numbers and delivery locations. However, as we scaled overseas, we uncovered situations where the norm we’re used was definitely not the norm. For example, in Thailand, we discovered situations where hauliers have zero idea of the above container details until the job has started. In this particular scenario, the trucks are essentially like a flag-down taxi, where no prior booking was made and information is only available when the “passenger” is loaded.
As a result, we realized that we needed a robust system that was able to accommodate all these different processes. The previous system was not built in a way where we could easily replicate modules with their own processes. It was possible to replicate the system, but would take a lot more time and effort to do so. Thus, we decided to bite the bullet and rebuild our product for international purposes from scratch. To signify its importance, we called it Haulio Zero.
Multitenancy & Its Benefits
Previously, Haulio’s software architecture was single-tenanted. Conversely, multitenancy is where multiple independent instances of one or multiple applications operate in a shared environment. The instances (tenants) are logically isolated, but physically integrated. Simply stated, in single-tenant, a single computer node can serve a tenant and in multi-tenant any tenant can be served by any computer nodes.
Tenants have shared applications and database instances and may also share hardware on which virtual machines or servers run. This enables easier maintenance. If one of the computer nodes were to go down in a single-tenant architecture, that means a customer cannot access their instance. Conversely, in a multitenant architecture, we can take that computer node out of the pool. Application deployment also becomes easier for the service provider as only one application instance has to be deployed instead of hundreds or thousands.
Even though all tenants share the same application instance, it appears to them as if they are using a dedicated one. It offers a high degree of configurability, enabling customers to create their own look-and-feel and workflow within the application. An additional layer can be provided for customization while keeping the underlying codebase constant for all users.
There is no need to update every instance of the software across a large number of servers. With a multi-tenant architecture, only a single, central application or codebase needs to be updated. Computer nodes running the latest version of the software can be released when ready and service providers can switch the traffic over, achieving a zero-downtime upgrade.
In short, multitenancy simplifies and speeds up upgrades, improves the utilization rate of hardware and databases, and reduces the overall development and deployment costs, superseding the single-tenant architecture in many areas. There are still challenges regarding security and confidentiality of the data, but they can be tackled to maximize the benefit of multitenancy.
Our Success So Far
We started working full force on Haulio Zero in Feb 2020, but the idea first started brewing in Dec 2019. Our first release to ESCO was completed by end-March 2020, and we have been releasing an update every 2-3 weeks since then.
Prior to using Haulio, ESCO largely adopted email as its communication tool with their hauliers. Every morning, they would update their hauliers on the new jobs that are coming in the day. Another email will be sent in the afternoon containing status updates. There would be another email if there are any new jobs. ESCO would also call hauliers directly to check on statuses if necessary.
With Haulio Zero, ESCO simply used it to allocate jobs to their hauliers directly in the system. Jobs are dispatched there and can be accessed by hauliers and drivers directly, affording ESCO with real-time visibility of their job statuses. At the same time, Haulio Zero is also built to interface with six different ports to get the correct data points so that ESCO and their hauliers will know what time the drivers enter and/or leave the port.
In just 4 months, we have more than 250 users in Thailand and transacted more than 10,000 TEUs. We are slowly scaling up the system, but building a similar process can now be done in hours, instead of days or months. The Haulio Zero tool is also available for companies who wish to manage their hauliers or fleet easily.
Lessons Learnt
When building a system, it indeed important to look ahead so that you can prepare for the present to prevent a major overhaul in the future.
That being said, we also understand that it can be hard to predict how your business might evolve over time. Things change depending on process and requirements, as well as the available technology at any given time. It can also be costly to adopt a multi-tenanted system right from the start, and thus it is crucial to constantly be open to change.
As quipped by Sebastian Shen, our co-founder and Chief Product Officer, “We did what we needed to do as we needed to build a minimum viable product (MVP) at the start. But as things changed, we knew we had to make tough decisions. If you asked me if I would have done things differently knowing what I know now, I would still do things the same way. Multi-tenancy didn’t really make sense when we first started, but things have changed as the business grew – when we grew and expanded our suite of solutions and discovered new value propositions. Overall, it was a good learning process for myself and my team. There will be even more technical challenges ahead and I can’t wait to see else we didn’t anticipate. Whatever it is though, I’m sure our product and engineering team will figure it out!”
Keen to find out more?
Whether you’re a haulier or you need containers moved, contact us via the form below to see how we can support your business!
