Kevin Soltysiak

Web developer - Ruby on Rails


deliver.ee is a french start-up whose goal is to make deliveries as easy as possible. They allow businesses to offer their clients same-day delivery for instance, but anybody can use the service and do one-off deliveries, all of this without having to care about the carriers' logistics.

The product revolves around a central service, an API made with Ruby on Rails, and several web-applications. At the beginning of September 2014, Sébastien (CTO of deliver.ee) was looking for someone that could help him finish some of those applications before an important deadline.

Three applications were concerned, all made with ember.js. I started working on the project under the guidance of another developer and took over as lead developer once he was no longer available.

"Pro" is the application used by businesses to order deliveries and follow them. Once logged in, the users land on a dashboard where they can glance at some statistics and monitor the state of their latests "missions". A mission is a request for a delivery and evolves with the time, from "pending" (just requested) to "fulfilled" (the client got his package(s)).

Pro: the dashboard interface

The main page of the application is the one where a user can request a mission. This page needed to be packed with all expected features while staying clear and easy enough to use, and this was not always an easy task.

In the end, we're using "blocks" to delimit the content, a UI pattern used in all of the applications. At the top is where users fill the start and end addresses for the mission. They can either fill a new one, or use one already supplied from a previous mission. This is also where they configure how the delivery/withdrawal is secured, and where they'll be notified if the area is not covered by the service.

After, they can pick a duration for the delivery and either hand-pick a date and time, or choose one of the predefined slots. Then comes the vehicle selection and the package settings: only one of them is required to be filled. And finally, they can supply a internal ID number, and configure how they wish to be notified for this mission.

Pro: the interface used to request a delivery

The rest of the applications revolves around mission monitoring and "resources" handling: users, permissions, addresses, warehouses, notifications, settings, ...

Pro: one of the settings page, the notifications

This application is also translated in both french and english. Users permissions are finely grained, as well as businesses' (through quotas of missions).

"Cockpit" is the application used by the deliver.ee team to display, monitor and handle everything: missions, users, companies, carriers, etc.

Cockpit: the list of missions

Everything can be done through cockpit: complete management of every entity. The team can follow and update missions, including manually dispatching missions to a specific carrier, and even order missions themselves for a business, with the same interface as the one in the Pro application.

Cockpit: the list of companies

Cockpit: the view for one company

Cockpit and Pro have a lot of screens in common with only minor variations due to the design of the page and the permissions handling. Therefore, I organized the projects so that all common elements were shared. This was important to ensure that future updates would not require changes in two or three places.

"Carrier" is the application used by the carriers to receive delivery, follower, and update missions. It is optimized for handheld devices, specifically smartphones. While not as packed as the two others, this application has some very specific features.

The carriers can see three lists of missions: the ones they are allowed to handle, the ones they are handling, and the ones they were specifically asked to handle. They can either accept or refuse those.

Once they have accepted a mission, they have access to a map indicating him where he has to go to fetch the package(s). Whoever gives them the package is required to sign (on the phone screen) to validate the action. And the same goes on for the delivery: the client also has to sign.

Each action updates the status of the mission, which can also be failed, refused, or rescheduled. And considering mistakes can happen pretty easily on touch devices, the carriers have 5 seconds to cancel an action after it was done.


After a few weeks of work, the deadline was respected, and since then I was involved in maintaining the applications, integrating new features, fixing undesired behaviours, and helping Sébastien learn his way around Ember.js and the different code bases. The various projects were very interesting and the team very supportive and fun to work with. I wish them nothing but success in their future.


Need help with a project using Ember.js ?
  • From: september 2014 to february 2015
  • Languages/tools: ember.js, ember-cli, node.js, ruby on rails
  • Some missions:
    • conversion of an ember app from ember-appkit to ember-cli
    • code-sharing via an private ember-cli addon
    • internationalization/localization of an interface
    • teaching/helping team members