How does the use of new technologies and third-party developers cause problems even though they look great “on paper”? The answer is that it creates poor communication between the customer and the launch teams.

Itera Research’s rule of thumb: If analysis can be done, do it. 

In this case study, we explore exactly why we adhere to such a policy, and what information it can give us.

May the stars show you the way!

Our study starts with a mobile application for astrologers. This app provides various horoscopes, tips, parting words, and checking the compatibility of the horoscopes between people.

The client has a subscription which includes 3 levels – Basic, Student and Master. Each level gives more and more benefits. The subscription can be either monthly or yearly and includes built-in awards, amulets and pendants (but only their digital counterpart).

The user buys all sorts of virtual amulets in the game and puts them on himself in this application. It also monetizes through advertisements.

Which platform to use as a framework

In the process of discussing platforms, we came to the conclusion that we will make a UWP application that will be released for two platforms at once – iOS and Android. The reason – after analysis such a decision was dictated by the cost – the development of one UWP application was equal to only 120% of the cost of one application for one platform.

To do this, we decided to use the Flutter framework, which already has everything you need to create applications for all popular platforms.

For first-time listeners, Flutter is an open-source development kit and framework for building mobile apps for Android and iOS, web apps, and native apps for Windows, macOS, and Linux using the Dart programming language, developed and maintained by Google Corporation…

Our main problem…

Developers from different companies worked on the project. Toward the end of development, when the application itself was finished, we began to add various libraries to it: analytics, payments, advertising, etc., and that is when difficulties began to arise.

The main cause of the problems was the third-party team – we did not have access to the programs themselves, or the code, making it impossible to fix anything or help them in any way. We spent a lot of time setting up and sorting through various libraries to make everything work at least at an acceptable level.

But the real difficulty was communication and timely resolution of problems that arose since we were back-end developers, while the other two developers were third-party. They were engaged in writing applications on Flutter directly on platforms (Android and iOS)

The project manager and tester were also from Itera Research, but it was still a long and painful process for both the development team and testers, as well as for the customer. The process of setting up the libraries lasted three weeks, which was agreeable to the client.

Why was it important for us to set this up?

Since this is a mobile application, operating systems prohibit the connection of payment using third-party services – MasterCard, Visa, etc.

All mobile apps work using internal payments with which Google and Apple work. This makes it, so they have their dashboard, settings, and subscriptions, and all payments go through their services only.

This library allowed the application to send requests to Google and Apple pay points and make payments within their services, that is, a kind of payment connector.  Such technology is called “In-App purchases”.

Timing is everything…

We were severely limited by the deadlines due to constant delays in the work process adding a level of challenge. Another problem was in the technical part – the server was not ready. We could not properly test the application or interact with it, even at a basic level. There were not enough resources from third-party developers, creating a significant amount of time we sat idle. Additionally, the third-party developers were also frequently idle due to the inability to check the performance of their applications. As a result, this downtime greatly interfered with the development process.

In such a situation, it is always important to devote time to work and communication with the client. Try not to panic him, but competently discuss the current state of affairs, show the results already made, and let the client test his application with his own hands. It was this approach that helped us maintain relations with the customer and complete the project, albeit with difficulties and missed deadlines.

The project itself was designed in two months, and we provided the finished product after 4 months, but only the Android version. With the publication of the application in iOS, we had to do a lot of magic. You can read about it here.

What else did we include in the development process?

We experimented a lot with payment, advertising, and analytics libraries. We constantly tried new options and changed existing ones until the result satisfied us. There were technical difficulties in making the functionality that the customer wanted. And, we had to make a lot of effort to make it all consistently work correctly.

Therefore, you might say that at first glance there appeared to be simple solutions given ready-made libraries, but this brought complexity that had to be adapted to a new project.

Native app or Cross-Platform?

If we talk not only about money but about the manufacturability of the application itself, in terms of convenience and other things, we might ask which is better. 

With native applications, it would be easier to integrate third-party services, as there is more documentation and ways to work with code and programming languages.

If the customer had chosen native applications, then it would be easier for the development team, and it would take less time to test. But in the end, we found that a cross-platform application was cheaper for the client. It takes a little longer and is more expensive to make native applications, while the cross-platform application causes less stress, nerves and risks. Since it was stressful for both the development team and the client, because many things did not work, we had to allocate a budget to fix and adapt all this.

Astrologers sum up…

Our team faced a lot of difficulties both technically and with communication. The biggest challenges were caused by the fact that there were outsourced developers to include. They worked remotely, which made the process of communication and interaction more difficult.

In the project itself, we had to take on the role of leaders in development. We gave recommendations and advice, issued technical specifications to all teams, and constantly communicated with the customer. 

Taking on a leadership role, while at the same time taking full responsibility for the project, it paid off – the product was completed, and the customer was satisfied.