Custom Platform for
Azati helped a European startup to create a custom logistics platform. It helps shippers to track goods in a real-time, as well as guarantees that the buyer will receive the product in a perfect condition.
If today’s retailer wants to stay competitive, it is essential not only offer high-quality goods at a lower price but think about shipping in advance. As shipping can not only help to build a good reputation but also can destroy even the most successful brands in seconds.
When a company has satisfied the demand in a small region, it is time to expand business interests to other locations. What concerns retailers, international shipping is a must, as it helps to cover huge regions and improve overall sales.
But international shipping is not a hassle-free process. Even huge European companies like DHL, DPD, FedEx or Royal Mail often fail to deliver in time and ship goods in a mint condition. Even more, quite often, local companies have a better reputation than transportation giants.
Our customer created a platform that connects these small companies with retailers and manufacturers. The company raised several millions of euros in series A funding and built an MVP. It is time to move forward and enrich the existing functionality, as well as develop new features.
As the core of the project and main modules are coded with Ruby – our team perfectly suited for this project. Our Ruby engineers are familiar with a startup workflow and had already created a bunch of applications for various industries.
The customer had created a partly operational prototype, but the users wanted him to improve the existing functionality to make the solution even better. This is why he decided to attract several developers into the project to finalize the MVP. Hiring local Ruby experts had become extremely costly, that is why the customer was looking for remote Ruby experts. He decided to give us a shot.
While several engineers helped the in-house team develop core functionality, others were responsible for the integration of third-party services. There were several challenges our team faced.
As the main goal of our team was to integrate third-party services and APIs, there was an issue of a lack of complete documentation on these services. As third-party vendors developed all services, we spent some time digging how these applications work. All the modules were built using different technologies and programming paradigms. There was a high level of unconsciousness in the documentation of these modules.
Our customer provided complete documentation concerning the project features. It means that even we did not have access to the majority of source code, we could look through the documentation and understand how the solution works. This information helped us to translate the data obtained via third-party modules into a format that can be easily used by core development team.
A lack of domain knowledge was another issue our team faced. Before this project, the engineers never faced a project in the logistics or transportation industries. It took some time for us to understand how all the processes work, dig into new terms and abbreviations.
When you earn a basic understanding of how the industry works under the hood, it is easy to predict the outcomes of your actions. If you know that a report or module requires a specific set of fields or incoming parameters, you can create better app architecture or propose an effective solution to the existing issue.
Another challenge was related to general application performance and third-party module testing. The core API of the system was built around a solid and well-tested code basis, but there were several issues with third-party modules.
Our engineers learned how to integrate these modules without any particular information about the internal functionality. The only way to find out this information was to send a request with a set of parameters and investigate the server responses.
As this solution was created as a mix of microservices and lambda serverless functions, it was hard to test them out. It was a usual thing when one service had changed its input parameters and output results, while other services expect to see the unchanged data.
This issue is typical for all projects built with microservices. For that reason, our team involved a quality assurance engineer for a week or two to speed up a testing phase.
Our team joined the project to finalise the MVP. This application was among those projects, where the workflow and development processes are built according to recent project management methodologies and techniques.
About 85% of all code was covered by unit, functional, and integration tests. Extensive comments described even the less significant features or architecture patterns. It took us less than a week to dig into this project. As we mentioned, our primary objective was feature enrichment, bug fixing, and module integration. Nothing the team couldn’t cope with.
From the very beginning, the customer invited our engineers to take part in all meetings for the internal team. It helped engineers to understand not only the solution but also learn how the whole industry works.
Developers spent some time doing initial research to investigate how third-party modules work. These integrations were a kind of “proof of knowledge” for our team. After that first test, our engineers joined the project team as regular members but working remotely.
The solution is built around progressive architecture: a mix of microservices and serverless functions of AWM Lambda. There are many small modules and niche functions hosted in the cloud. All this code is connected to several comparably huge RESTful API’s called «Services». Let’s have a closer look:
ETL (extract, transform, load) service. This module sends pieces of data to cloud functions and processes the outgoing results. and cloud functions.
For example, a user can upload a CSV document containing all information about tours or orders. This document is sent to a cloud function that processes it and returns a structured output. Such an approach significantly decreases maintenance costs and average load of the system, helping it to act more efficiently.
Despite the challenges mentioned above, our engineers successfully integrated several mission-critical third-party providers and their modules into the existing infrastructure. We also developed several impressive features which greatly improved the workflow of a customer.
Bug fixing was a thing our developers faced on an everyday basis. While working in the startup, even developers sometimes do someone others’ jobs. It is easier to fix a critical issue when a developer finds it, than assign a task to another developer and wait for a solution. Such an approach helped a project grow faster and deliver the result to end-user before the deadlines expire.
This project also helped our team to improve its technical expertise, as every startup prefers modern technologies over a traditional technology stack. Achieved knowledge is important when you are developing custom tools for enterprise sector.
While engineers are creating custom software for the enterprise, they prefer robust tools they already mastered. Sure, it helps a company to deliver reliable software, but it dramatically increases the amount of time needed to roll the first version into production. If you had mastered a tool while developing a startup, you could easily apply it to any project.
Almost a year and a half have passed since our team applied for this project, and it still keeps going. We are happy to say that our engineers help the customer grow faster delivering an outstanding experience and accelerating the whole European transportation market.
What concerns our team, the customer is fully satisfied with the results. Even more, before inviting remote developers, he considered outsourcing to be something complicated and stressful. Hopefully, our team proved not only its experience and efficiency but convinced a customer that the outsourcing works pretty well.
That is why if you want to streamline the whole development process, you’d better start from building your local or in-house team. If you have already created main processes, it is easy to integrate any number of remote developers into the workflow.