Live event and talent discovery community platform

Solution

Analysis phase

To understand the current state of the project, we started with an analysis of work that has been done before. We looked through the project’s documentation and backlog to find out existing flaws and improvement points. The main issue Itransition found was the lack of project structure and clear goals. To streamline the work process and set clear project goals, we suggested hiring a business analyst. Together with the BA, our team structured and prioritized the backlog.

Android adaptations

While the customer used React Native for the app development, they created the first version without taking into consideration Android-specific features.

First and foremost, our team created additional logic for the physical back button that all Android-based devices have. The second issue Itransition addressed was the usage of modal dialogs, as the Android system doesn’t support them. A modal dialog looks like an additional window that pops up on top of an app screen. After the user closes a modal dialog, they can once again interact with the app screen. iOS devices don't have any issues with modal dialogs since iOS doesn't have a physical back button. However, if an Android user closes a modal dialog by pressing the back button, they would return to the previous screen, not the one where they opened it. Additionally, modal dialogs use more memory to run because the device has to render two windows at the same time, which can slow down the application. Our team resolved these issues by using non-modal dialogs, thus improving the overall application speed.

Payments module

After conducting the analysis and defining project goals, our team focused on fixing legacy code and implementing new features to the payment module. As the platform consisted of many different modules, Itransition created a front-end components library to reuse them in modules and be more time-efficient.

When Itransition started the project, the payment system didn’t work properly. To start working with the platform, businesses were required to pay a subscription fee, and the payment module couldn’t support the payment. Our team rewrote the code, resulting in a payment module that supports both ticket purchases and subscription transactions.

Another issue we fixed was asynchronous transactions, which occurred when several clients were trying to buy the same ticket. We prevented it from happening by locking the ticket on the operator's side while the payment was in process.

Tax calculation system

Since the US is the main country of the customer’s operation, they have to calculate and submit numerous tax reports, as different states have different tax policies. Moreover, the taxes must be calculated according to the shipping address of each order. Without a proper tax calculation system, the customer’s accountants had spent hours calculating taxes and creating monthly reports.

To automate the process and minimize human errors, Itransition suggested using external software for tax compliance. After conducting a comprehensive analysis and comparison, Itransition suggested Avalara as the software with the broadest global reach. While other systems are supported only by the US or the EU taxes, Avalara is integrated into 190+ countries, which is a great deal, especially since the customer planned to enter new markets. Having Avalara instead of multiple services would result in fewer dependencies, and we could expect the same level of service in all regions.

Thanks to Avalara, we didn't have to integrate a whole US tax database into the customer system, however, we still had to find a way to connect all the products and services on the app with their tax codes. This was an issue, considering the amount and variety of different businesses (artists and labels, sports facilities, movie theaters, etc.) that were presented on the platform. The main reason each product should be labeled is that each state in the US can put different taxes on the same item. Eventually, Itransition’s team created an algorithm that assigned permanent codes to the products displayed in the app.

The algorithm assigned codes based on four rules:

• product producer — it could be either the customer’s product (ex: paid subscription) or a third-party product (any other product or service that was not made by the customer);
• the product type: subscription, event ticket, etc.;
• product category (ex: sports - football);
• product sub-category (ex: football - NFL).

By implementing Avalara and creating a code-assigning algorithm, the Itransition team delivered a fast-working tax calculation module that calculates the amount of taxes on each product on the fly and displays them directly in the client’s cart. Thanks to it, the customer ensured automated tax compliance and accelerated the process as a result.

Reward program

The customer wanted clients to use the app as a social media and a buying platform, while businesses would use it as a selling and advertising platform. To keep clients engaged, they decided to create a reward program.

Businesses deposit dollars in their reward program account and set up a list of reward requirements. As a client fulfills reward requirements and gets reward program points, money from the deposit given for a reward is converted to bonus points and transferred to the client’s account. Then a client can use their bonus to purchase something on the platform. When a client initiates the buying process, bonus points are converted back into dollars, and then the payment system sums up money from the customer and ones that were converted from bonuses and purchases the ticket from a provider with real money.

Itransition also proposed additional reward conditions, such as signing up, visiting partners’ stores/venues, making purchases from partners, inviting friends to the vendor, sharing a post (internally or externally), etc.

News feed

Since the application was intended to be a social media one as well, the customer wanted each user to have a personal profile with the ability to create and share posts, create stories, and leave comments, likes, etc. In addition, the customer wanted to implement a news feed for entertainment and marketing purposes. On that feed, all types of posts, events, and artists’ account suggestions would be combined for each client. However, the customer wanted to have control over the users’ feed, so it wouldn't become oversaturated with one type of content.

For the first version of the app, the customer implemented a simple algorithm where they set an amount of content for each type of post, and the feed was created accordingly in real time when the end client opened a news feed tab in the app.

That way of feed creation was slow and inflexible because if the customer wanted to change the proportion or amount of content for each block, developers had to rewrite that piece of code. Moreover, this module often overloaded the system while running, which led to a complete or partial shutdown of the app.

To fix the overload problem, our team suggested a different, more flexible approach. Itransition wrote a new algorithm that gives each piece of content a rating according to its number of views, likes, or comments based on a certain period of time. The content is rated and then sorted from the most rated to the last. That way, the news feed can be created faster, so the end user gets a smoother operating app and the customer can control which metric to prioritize for the rating.

Results

Itransition delivered a fully functioning social media platform for the customer, and the BA helped structure the project, resulting in the project being three times more time-effective.  

After the release, the Daily Active Users (DAU) increased by 40% in the first month and monthly revenue increased twice. Also, the tax calculation system reduced the time and effort required by the customer's accountants by 30 times.