Code Base as a Living Entity, or the Power of Iteration

How meticulously defining an MVP, fluid communication, and realistic estimation influenced the launch of Cabify Delivery in record time.

In March 2020, amid some historic results for the company, COVID-19 hit the world. Of all economic activities, there is no doubt that sustainable urban mobility has been one of the hardest hit by the pandemic.

It is against this bleak backdrop that Cabify Delivery has been developed. Many of you may say it is thanks to positive karma, but I prefer to see it as two-way value delivery.

Let’s, however, continue with the series of events. In the face of an unprecedented catastrophic situation, Cabify could not stand idly by. For this reason, different areas of the company set out to drive various initiatives in order to help their fellow citizens. Simultaneously, and organically, our users pushed for a new service.

I can imagine the look of disbelief on the face of the driver who, for the first time, saw how the passenger seat was occupied by a package with an addressee. This is how Cabify Delivery came about, to complement the existing services. It is a line of business that the company offered us, I would like to believe, by way of thanks.

Precise MVP definition to develop a high-quality product

The lockdown was not a rejection of our service, but rather a stimulus to evolve. Among the major product challenges ahead of us, it is worth highlighting the following:

Managing packages instead of people.
Up to now, we have been used to transporting people from A to B. Moving belongings, however, from addresser to addressee, is a radical change of the system.

Adding multi-stop is an essential requirement.
With the addition of package routing, multi-stop is a strategy for space and resource optimisation, as well as a must-have for many of our users.

Packages are picked up at one point, (or two) and delivered at as many, or more. One route, endless possibilities.

Drivers become transporters.
As software developers, we are in charge of creating the platform. It is the drivers, however, who truly represent the company to the users. If it is a Cabify Lite, for example, they drive safely and carefully, keep the vehicle clean, COVID-free, and offer the best of care.

Simplifying things greatly, our first driver usually heads to the pick-up point and ensures a smooth journey to the chosen destination. Incidents may occur, but usually the ride ends with the rider’s assessment. The driver rarely gets out of the car.

With shipments, the paradigm shifts, and drivers take on an even more active role. They must contact the sender and receiver, park, leave the vehicle, and make sure they locate the right person by following the instructions given.

In the worst-case scenario, the journey may end up where it started.
We have just described the happy path, but everything can go awry if a package does not arrive or cannot be delivered. Do not fear; Cabify has solutions, although explaining them would take an article of its own..

Real-time notifications to all the actors involved.
We will bring a new product to market, following the Lean Start-Up methodology. Never, however, will this be at the cost of our own quality standards. We bring about a strategic improvement by notifying the sender, the driver, and the receiver of the packages. Foresight allows us to reduce potential delivery failures.

We could go on to a list of multitude of extra functionalities, (drop-off point reordering or route optimisation, to name but a couple), but not for this first interaction. We had one goal: to get it out there. Do remember our promise to add value, both to our users and to society.

Putting Faces and Eyes on Ideas

When it comes to launching a product, ideas mean nothing if they do not end up as something tangible. The more information, the better the decision-making process, and we had invaluable first-hand experience.

Design with the user in mind.
We are professionals: We love our work. That is why I can fully understand all designers who rely on certain stylistic patterns before making UX decisions.

In an MVP, the goal is to go to production, but first impression counts, and a lot. We do not want to launch an App that causes visual rejection. On the other side of the scale is the pragmatism of business: a beautiful contradiction that need not live in conflict.

Focusing on this first iteration, perhaps the best advice I can offer is that details have a place, yes, but they can surely be prioritised for later. By recording each idea as a possible prototype, you will soon have time to address them.

Communication and Consensus: Everyone united.
In my opinion, and owing to the great attention I pay to the UI, the design must be attractive and consistent. We have already mentioned that MVP can accommodate iterations, but of all the above, the design is perhaps the most constrained. Outsiders may well see design as a sort of bunch of modules placed in a subjective way to please the public. Nothing could be further from the truth.

An effective design is loaded with logic, it must fit into the Design System in force, and it must adhere to the corporate identity. The mathematical and psychological component is undeniable. Therefore, one limb of our designer is being tugged by the business need; on the other three are his fellow designers, the developers, and even his own sensibility.

Set realistic boundaries with no loose ends.
With an MVP, new use cases emerge. In this phase, as a developer, I value fluid communication in order to detect possible technical and schedule constraints, check content, and certify flows.

Again, it is interesting to establish reasonable limits (among all the actors: EM, PM, Developers, Designers, Data Analysts, etc.) on how far the MVP will grow, also in terms of design. The main rule is not to leave the bulk of users at a dead end. Do not worry, edge cases will come along to disturb the peace.

The non-final code

The challenge was waiting patiently on the task board, and the development team was practically assembled. On the web, at least two front-end developers were needed to build a new UI architecture and one back-end developer was needed to adapt the existing infrastructure.

Good is better than perfect.
There is a quote widely used in the San Francisco Bay Area that gives the title to this epigraph: Good is better than perfect, kind of. This project makes perfect sense of it. If you thought this Silicon Valley mantra was nothing more than an ode to mediocrity, then read on.

Epics, cards and sprints, everything was ready to get our hands dirty. Without going into details of the implementation, we can highlight what my opinion is in terms of the keys to an agile and effective production rollout. The loop goes something like this: go out, measure, correct, and start again.

Together, but not scrambled
Before even throwing out a single line of code, the first doubts arise. I can tell you that Cabify Delivery shares logic with any other type of service. It seems intuitive to think that reusing existing code saves time and minimizes code duplication. In addition, the platform was assembled and tested: CI+CD pipelines, test tools and environments… as good as free!

Well, yes, but no, because, as they say, we’re getting on a bit. Then, a couple of factors pushed us into accepting a nuanced symbiosis.

First came backward compatibility. Our MVP could not, under any circumstances, negatively affect Cabify’s regular service. We were a new team, and the lack of context could cost us dearly.

Second, we did not want to plague the code with patches so as to integrate an MVP, because, if it went wrong, decoupling Cabify Delivery would have been more than just a headache.

In case there was any doubt, along came Dan Abramov with his WET codebase to dispel it. As a result, we all pivoted toward a hybrid solution that gave Cabify Delivery an identity of its own.

• Product designed a strategy to host Delivery on a dedicated path (URL) within the main site.
• Design approached a consistent UX based on Cabify’s Design System.
• Development, in turn, took the baton to leverage a solid infrastructure, building on a parallel file hierarchy and independent environments.

Recognition to the wise.
Fire team, that’s the name given to a just-created team made up of talented rejects. This graphic nomenclature perfectly conveys the double meaning of the concept it represents. The MVPs receive renewed enthusiasm, along with a bag of uncertainties.

Among the great successes in achieving Cabify Delivery on the web has been that of the knowledge and experience of the developers involved. That said, it does not imply carte blanche to interfere in the team’s roadmaps, but it is a network of valuable knowledge. I cannot imagine the number of bugs that could have been introduced without the proper context.

Development pace while assuming controlled risk.
As I have brought up in a previous section, the cards and epics paved the way to completing the launch. The board, far from becoming a control mechanism, was a status monitor; an accurate snapshot.

When the objective is joint, and everyone has the gregarious spirit of a cyclist in the middle of the peloton, frictions do not exist. I cannot overlook how pair programming dynamics and direct communication channels are generated, based on mutual trust.

Build, measure, learn, repeat
Once in the air, the mixture of equal-parts dread equal-parts satisfaction is inevitable, no matter how much time goes by. What can vary is how you manage it. In this occasion, we maintained the idea that our code was never carved in stone. In this phase, a certain moment of expectation is born, in which the only thing to do is to attack tech debt, measure, collect incidents, prioritise, and iterate; never stop iterating.

Cabify is a leading company in sustainable urban mobility, currently present in 11 countries, with complete memorandum to transform your city into a more comfortable place to get around and live.