Swapping Horses in Midstream of Delivery App Development Process

Starting the development of a standard app, you usually do not expect you would face challenges, questions, improvements, updates, or unpredicted issues. If there are hundreds of analogues in the app store, you consider it is not a big deal to build your app. So, you outsource the development with a light heart. However, sometimes it happens that you have to change a development partner because the previous one has not delivered the result. The possibility of switching an outsourcer for a mobile app development frightens product owners and paralyzes their will so that they try to find a remedy or negotiate the product delivery with the previous outsourcer as hard as they can. Such efforts may bring you the desired result, but usually, you simply waste some more precious time and do not launch the product at the market in time.

Switching to another contractor when developing an app is not a disaster. We, in DashDevs, used to work as a not-first outsourcer, complete the development, and release applications not-from-scratch. Dealing with the legacy code, we focus on market needs from the business side, and, from the tech side, on the delivery of a product version, which is sellable and valuable for its users. Ruben Delivery is such a case of an ordinary delivery app that stuck on the development for three years before our sci-tech crew has redeveloped it and guided it up to the release.

A simple delivery app with a non-standard approach

Every product goes through certain developmental stages. Why the product has been born, how it has been created, whose idea has inspired the product and for whom, what has been the result — these are the things that differ. With the described case of a mobile app, Ruben Delivery, product owners started with an idea of an app which offers the delivery services for a grocery, food, goods, and so on. Usually on the ideation stage, a business validates an idea. Latter the idea crystalizes into a vision and a mission of a product. Ruben Delivery app went the same road. The initial prototype of the delivery app has been redefined in the idea validation process and due to market research. The product has found a niche. The future product unique offer and value has formed into a CBD delivery app with the standard functionality.

The product: Ruben Delivery website and native apps for iOS and Android.

The market: Switzerland and the EU.

The target audience: Adults above 18+, with the core of men 45-60+.

The business model: the service of delivery of partners’ CBD goods to app customers addresses.

Reasons for switching a development partner for a delivery app

As soon as an app seemed to be a usual “one-from-hundreds” solution, product owners had chosen a development partner with fixed prices. This outsourcer offered the development under subscription. It was a pricing model when a client paid the defined monthly fee, and developers showed some progress with an app development within a defined scope. This model looked affordable, but the development turned out to be unstable. The timeline was unclear. The product literally stuck in the development.

That is the core difference between a bunch of freelancers and a development partner. We are the company which bears corporate responsibility for building the product from any stage and leading it up to its release.

Back to Ruben Delivery case, there were no responsible team or developers which were dedicated to the project. An outsourcing company assigned any developer at the bench to do bug fixes, instead of a continuation of development without ensuring knowledge sharing. It caused a patchwork-like coding and logical inconsistency in the app architecture. There was no concrete responsible person for this project at the outsourcer’s side. And, finally, the first development partner had not delivered the app.

So three main reasons for changing the outsourcer were:

• the development cost over stability
• working hours over responsibility
• process over the result.

Looking for a different experience with a development partner

Having previous experience with a development partner is helpful. Such collaboration helps a client to formulate expectations and decision-making triggers. A product owner tries to find a contractor who uses the same approaches and could possibly accept the product vision and share the idea. And what is essential, whether an outsourcer understands your business needs. However, it is only from the business side.

From the tech side, no matter how standard your app may be, you, as a client, should check what your next outsourcer business assets are. If a potential development partner possesses not only the required technology stack and resources but also specific knowledge and practice.

Furthermore, look at an outsourcer from the development management perspective. Ask how your partner about his usual business processes with the legacy code projects and how it will organize the working process with your product. Your goal is to deliver a profitable product and return development costs as soon as possible. And an outsourcer is expected to be helpful in achieving your goals.

The development partnership means engagement of both sides

When we, in DashDevs, get a client’s request, we share information about our practical expertise, technical skills, industries we serve, and our workflows. Also, we ask a business about its values, ideas, and approaches in order to get business needs, understand the pain, or obstacles we could help to solve.

We acted the same scenario with Ruben Delivery. We had defined the vision and business needs, set tasks to solve along with their priority, determined the possible scope, and the expected result. By a result, a business usually means a released app which earns. To have this done, we started with product evaluation. We did a code review, which was complicated and risky because there was no specifications or documentation. Besides our standards for code quality and approach to the architecture differ from what we saw as the source code.

After the code review, we made our conclusion and offered the solution for Ruben Delivery app, which includes:

• code revision & validation,
• investigation for problems,
• code refactoring & debugging,
• architecture & logic improvements,
• UI improvements,
• calculation fixing, and
• code unification.

As soon as DashDevs is a full-cycle software development company, a product owner also ordered a redesign of the logo, website, and clients’ UI of the app.

Improving Ruben Delivery app

It was hard to revise and validate the software. There was no specifications and documentation available. Developers should know business processes and analyze the code for its quality, logic, and relevance to those needs. The code appeared to be hard to read and understand. It was messed up and was not split to any blocks or flows that could simplify navigation through it. Dashdevs’ sci-tech crew practiced another approach to writing code and its quality compared to the initial code of the product we got for a review. The code review revealed weak points in the app architecture, calculations, and logic. The discovered issues meant that the app and not been tested before at all. After problems investigation, we offered ways to improve the code, complete the development, and release the product.

We did bug fixing and code refactoring. Our experts organized the code according to the flows it runs for. Data input and requests were optimized, so that data from several screens is gathered on the device into one bundle, and transferred to a server. Some business processes optimizations were made, in the way of reducing the number of notifications that a user receives after placing an order. Initially, the app notified about every order status change. For eхample, that an order is placed, then that it is paid, confirmed, or processed, or a courier with the order is on the way, and finally that the order is completed. Imagine you were a user receives up to 10 notifications for a single order! After the optimization, the app shows only those status changes that bring real value to a user.

The other big part of improvements was code unification. Our experts made the different versions of the app perform the same way, operate the same data, and calculate the same formulas. In the source code, there were essential differences that might cause possible failures.

Since we worked with the legacy code, our experts should find the balance between existing code and redevelopment. The primary goal was to deliver a stable performing app within the shortest time frame, not make its code perfect. That is why some fixes were not so elegant as they might be if we started development from scratch.

Ruben Delivery under the hood

Ruben Delivery is a native mobile delivery app for iOS and Android.

An app provides a client with functionality to order the goods from the partner shops, pay for the order and its delivery, and get this order at user’s address delivered by a courier.

The app uses a standard MVC (model-view-controller) architecture with UI storyboards (flows) and interface builder. There are two separate authorization models in the app for a client and a courier. For in-app purchases, the app uses Stripe with the support of Google Pay and Apple Pay, and a feature of adding a card.

What pleased our designers about redesign and UI improvements is a timeframe. They had enough time to create a new style, discuss it, and apply improvements. The initial color scheme was pink, white, and grey. After the validation, it turned out that this scheme did not fit the target audience (mainly men aged 45-65). Moreover, a business idea was also narrowed to a delivery app for CBD products. New logo and color scheme matched a redefined concept and business idea.

UI updates incorporated the version for a client mainly, while the courier’s version left almost the same. Some spinner and splash animations were created for the app loading.

Some UI improvements also included:

• big lists dropping changed from accordion to a convenient solution;
• combining into one screen order details, status, and delivery tracking on a map;
• adding non-empty status and icons for the cart along with the items counter.

The new logo and section dividers were also used for the Ruben Delivery website redesign.

Challenge of releasing to stores

According to the current rules of the marketplaces, it is not allowed to release apps offering marijuana. Despite these rules, the App Store and Google Play both have CBD apps available for users.

App Store

1.4.3 Apps that encourage consumption of tobacco products, illegal drugs, or excessive amounts of alcohol are not permitted on the App Store. Apps that encourage minors to consume any of these substances will be rejected. Facilitating the sale of marijuana, tobacco, or controlled substances (except for licensed pharmacies) isn’t allowed.

https://itunes.apple.com/us/app/cbdelivery/id1437948624

Google Play

Marijuana

We don’t allow apps that facilitate the sale of marijuana or marijuana products, regardless of legality.

Here are some examples of common violations:

Allowing users to order marijuana through an in-app shopping cart feature.

Facilitating the sale of products containing THC.

https://play.google.com/store/search?q=CBD&c=apps

In the modern world, some cannabis-associated products are legalized in several countries, including Switzerland and the EU, where Ruben Delivery operates. Such a niche requires from the app owners additional accuracy and extra attentiveness in terms of product promotion and distribution. One of the possible ways to distribute the app is via a website or personal invitations. Another is to restrict the access for downloading the app from the marketplaces by users’ location. A product owner can make the app available only for the countries and markets where CBD goods are legal. In this case, the product owner will have to communicate with the marketplaces and prove the product’s legitimacy. Due to the fact that the legal usage of CBD products tends to spread, more and more countries have changed their vision and laws. App users, developers, and product owners expected that marketplaces would change their rules somehow to be consistent with reality.

Busting the legacy code development myth

Delivering a product not from scratch and in the jurisdictions with strict legislation is possible. The secret is in sticking to business goals and keeping the right flow of product development from the beginning. The result-driven approach, combined with strong prioritization, will help you to reduce resources and time to release. DashDevs is the partner who uses sci-tech achievements and practice to help you deliver a result. We evaluate and investigate first, then offer our clients a development workflow to release their business software within the optimal balance of time, cost, and quality. Our experience allows us to deal with digital assets from any stage of development. Ruben Delivery is one of the cases when a product owner changed an outsourcer and released the app, which means to make the business run. If you stuck with the development, let us see what we can do with your app!