Cmonjardinier

Cmonjardinier

Overview

Vincent is born to be an entrepreneur. Having a decade of solid experience in the personal care services area, he intended to create a platform connecting gardeners with individuals. The aim of this project is to disrupt this niche market by enabling individuals to obtain quick meeting requests and helping professionals increase their turnover. This initiative was particularly interesting for two reasons: first, the project holder profile: an entrepreneur who already had companies and broke the need to generate profitability quickly and who is aware of changes in his project scope. Second, the project itself: it deals with a major issue in a mature market … without digitalization.

Our Approach

We introduced a first budget that would cover the entire scope requested. Nevertheless, the resulting schedule made us hand over the project within 12 months, which automatically implies a large budget without the ability to learn from users. Given the need to obtain a rapid return on investment, we decided to defer certain so-called secondary functionalities in order to focus only on features that would bring benefit to the user.

Thus, instead of implementing a four- native app system (2 Gardener apps and 2 Individual apps), we confined ourselves to two native Gardener apps and a responsive website for individuals. By studying the target audience, we realized that booking a gardening service is a solemn occasion and that an actual comparison between providers was necessary. The choice of a simple and effective website was widely acclaimed by the UX team.

During the development phase, we made the exotic choice of splitting modules on the basis of platforms. Accordingly, the iOS app and the server represent different modules, and so on. Rather than developing these modules parallely, we performed them in a subsequent manner. However, this approach has a certain drawback: it requires a flawless initial design and architecture in order to guarantee that the modules integration takes place under optimum conditions. Still, by imposing this approach, the teams naturally documented and tested their code well beyond what we usually perform.

Findings

Integrating several technical units developed by different engineers carries a high risk of inconsistency. Thanks to the architects’ investment, the different modules were integrated with each other without any functional regression, which represented our major concern. Besides, since the project was launched on March 1, 2017, the delivery took place by the end of July 2017, i.e., it took us 5 months of Design and Development! As for the actual testing phase, it was carried out in September 2017. By that date (November 2017), we had integrated a set of analysis SDK in the apps and on the website to identify the bottlenecks and optimize the system. The latter succeeded in generating turnover 3 months only after it went into production.