Previous projectNext project

SmartSeeds — uber like solution for the grain truck market


LocationRussian Federation
SmartSeeds is a service connecting both cargo owners and cargo carriers in one system to complete mutually beneficial transactions on the transportation of grains and oilseeds. Initially, it covers RF, but with time it is envisaged to work in other CIS countries too.


This service integrates several types of users at the same time. From one sight there are grain owners and grain traders. They are interested in cargo delivery from the elevator after harvesting to the terminal or port from where this cargo is sent to the destination. One of the features of the transportation process is the volume. Cargo can reach up to thousands of tons and it is necessary to have many trucks available. Also, cargo can not be in stock for a long time and has to be collected in time.

Before the launch of SmartSeeds cargo owners that don’t have proper vehicles had to solve this problem with own efforts by searching carriers. Moreover generally more than one carrier is required to handle the transportation process in a limited time due to big volumes of cargo.

    Benefits for cargo owners

    This service was created first of all to simplify and systematize search of carriethe rs and to minimize the volume of bureaucratic procedures while organizing transportation pthe rocess. For the cargThe service has an interface similar to a Uber-like anpp. It is sufficient to choose a place of cargo’s departure, place of destination, indicate loading date and type of ag,riculture crop. The rest of process includithe ng submission of request applicathe tion, closing the request, price increase, monitoring of cargo transportation, requests procesrequestough all the stages of business logic will be arranged by the system.

      Benefits for cargo carriers

      From the other side of the process, there are cargo carrier. Generalcarriersy are companies or individuals owning either a huge truck fleet or few vehicles. Rarely one owner is able to canthe request. And there are various reasons explaining this: short terms, big cargo volumes, no vehicles available at the moment. Hence there is one more feature of the service: it helps carriers to perform small trucking in frames of one big request of the client. Cargo owner doesn’t choose any carrier precisely because he shouldn’ttheye much concerned about it. He just publishes the request and waits for it to be performed in time. For a carrier, it is sufficient to have a truck available and respond the request. Wheto n the request is taken away completely all the carriers proceed to work.

      The role of drivers in the system

      There is one more role in the system – driver. Drivers are fixed by precise vehicles that belong to carriers. Driver’s task isThe driver’s he has to complete the request: load the cargo on the loading point, transport cargo and to disembarkation point. There is a mobile app to manage the transportation process from the driver’s side. Due to the app driver can change current stage ofthe request completion and exchange information with the support service in case of unexpected circumstances. Moreover in order to motole’s moving there is a GPS sensor installed on each truck. GPS sensor periodically sends coordinates to our geo-information service (GIS) where these coordinates are processed and analysed to deteanalyzedind of situation: entrance-exit from Geo zones, deviation from the route, signal loss, downtime.

      Also, there are representatives of the terminals in this business-processbusiness processnal working in ports and willing to receive information about transport that is about to arrive at the port for disembarkation.

      Architecture and components of the system

      The work on the project started from the studying of the field and all business problems both in text and in graphics. Simultaneously server architecture was under development and technologiesthe needed were chosen. Since we are developers experienced in PHP-framework Symfony, we chose it for the realisation of trealization logic of the service. Our system was separated into several components that were developed separately.

      • API —the heart of the system, through which all the transactions are made;
      • Frontend — client web-interface whweb interface register and manage the requests from private pprofiles
      • Backend — web-interface foweb interfaceors to control and manage the system;
      • GIS — geo-informational servicethath processes coordinates from vehicles and transfers information on various business events to API;
      • Mobile app for the driver – an app used for management of the cargo transportation process;
      • Mobile app for cargo owner and carrier – completes functions of web application in the form of a native application on Android and iOS.

      External services

      There are several external services used in this system. For example, Wialon was supposed to be used only as external Gan IS. It was planned to be integrated with our system and complete all the necessary tasks for this project. But in order to maketore independent from external factors, we implemented all the required GIS functions ourselves. Herewith internal system process can beprocesseslled much easier. Wialon remained only as a re-translator of GPS-signal that GPS signalata from the vehicle’s sensors and then re-translates it to our system by TCP. In order to rToproceed low-level data, we developed decoder of GPa S tracker protocol in Python language. We used MongoDB as a store of big data about vehicles vehicle/p>

      In this project, many tasks had to be rendered in asynchronous background processes. For this, we used queuing sethe rver RabbitMQ. There we sent such tasks as sending notifications to participants of the system via different channels, processing of information about events during transport movement, communication between API and GIS services and much mo,re.

      Also, we connected Firebase Cloud Messaging to this server for sending push-notificatiopush notificationsatforms and Infobip for sending SMS. Moreover, we connected API of such servthe ices, as Selfon and "Central Bank of Russia" to receive information about registered legal entities and simplify the process of registering users. To draw routes and generate static maps, we use Google Maps API.

      There is a possibility to manage system settings inthe administrator’s interface, for example:

      • edit various reference books: brands and models of vehicles, embarkation and disembarkation points;
      • verify users;
      • manage requests;
      • set transportation tariffs in different regions;
      • review statistics;
      • edit texts of messages and notifications;
      • manage notification sending channels according to every user type and event.

      “1C Accounting” is integrated into our project to manage documentation and draw up invoices. Integration was conducted by the team of developers from Moscow arranged by the client.

      Total amount of developers that participated in different stages of project development from our side is more than 20 people. They are: 9 back-end developers, 2 front-end developers, 3 Android developers, 2 IOS developers, 2 QA managers, 2 project managers and 1 DevOps. Also, in the development process, we were communicating with client’s representatives: designers, technical specialists and field specialists.

      Adapting to changes in business logic

      Requirements and business logic were changed for few times during the process of project development. The reason was the customer was applying more efficient business model regarding market demands. For example one of such changes was breaking down of the request by a carrier. Since elevators have the physical limit of tons to be loaded per day and cargo volume can largely exceed this limit, such term as lot was added.

      The request is broken down to lots of equal or different sizes. One lot is actually one day and a number of tons allowed to be loaded to the elevator. Then carriers operate parts of the lot: if lot is less than 300 tons carrier can take for example only 20-25 tons depending on carrying capacity of a vehicle. Part of the lot is a track performed by one driver under request. Due to iterative development of the functions, we managed with an adaptation of changes mentioned.

      Both cargo owner and cargo carrier can follow the process of transportation. This information can be viewed online.

      There are many complex elements of interface used in this project. In order to ease work with these elements, our front-end developers created some components on Vue.js + RxJS. For example, a map showing transport moving, asynchronous input fields and our own implementation of the Select element.

      RxJs library was used for implementation of address search. Due to this library we can filter user's data entry stream and optimize amount of requests to the server. In result user has access to a live search and business has fast and high-quality solution that is easy to maintain in future.

      Future plans

      According to the intentions of the project's customers, after the end of development, this web-service is supposed to cover all business processes between different players in the system. Also, there is a plan to integrate new roles to the system in the future, such as a representative of farming entity (same as personnel at the terminal, but at the point of embarkation), various types of managers in frames of cargo owner's and carrier's roles, account for fiscal services. It is planned to expand the range of functions of user accounts. At this stage we implemented MVP consisting basic functions that let service to be launched in time, show itself on the market and attract first users, register vehicles and drivers in the system and create and calculate first requests.


      • Vladimir Sutowski
        Vladimir Sutowski

        Project Manager

      • Ruslan

        Front End Developer

      • Andrey Siagrovskyi
        Andrey Siagrovskyi

        Front End Developer

      • Andriy

        Front End Developer

      • Sergey Zheleznyak
        Sergey Zheleznyak

        Back End Team Lead

      • Artem

        Back End Team Lead

      • Mykhailo Vilshansky
        Mykhailo Vilshansky

        Back End Developer

      • Alex Litvin
        Alex Litvin

        Back End Developer

      • Yevgen Zholkevskiy
        Yevgen Zholkevskiy

        Back End Developer

      • Yurii Svatok
        Yurii Svatok

        Back End Developer

      • Sergey Veretilo
        Sergey Veretilo

        Back End Developer

      • Max Logvinenko
        Max Logvinenko

        Back End Developer

      • Oleksandr

        Mobile Team Lead

      • Anton

        Android Developer

      • Oleksandr

        Android Developer

      • Viktor

        iOS Developer

      • Yevhen


      • Misha

        QA Manager

      • Igor Harbuzyuk
        Igor Harbuzyuk

        Project Manager

      • Svetlana Bolgar
        Svetlana Bolgar

        Project Manager

      Other Case Studies

      • BenzinPreis24


        Service for efficient search of petrol stations in Switzerland

      • MeinFernbus Apps

        MeinFernbus Apps

        Mobile app development for the German largest passenger transportation company

      • Airfarm


        An independent agro network app, Germany

      Contact us and we'll be happy to create something awesome for you


      • 10K
      • 20K
      • 50K
      • 100K
      • 150K
      • 200K