Case study: How Latta helped Warezio to develop features without stress

What is Warezio?

Warezio is a SaaS startup providing services aimed at protecting digital content against piracy and illegal sharing. Their technology helps companies in industries as diverse as film production, livestreaming and software identify and block illegal copies of their content online. Their services include protection against torrents, illegal streams and abusive social media accounts.

In addition to its backend, Warezio provides its clients with a web-based user experience where they can monitor the progress of the search and deletion of illegal content and set up the service itself. Setting up the service involves defining a portfolio of works that will be protected by the service.

The biggest problem face by Warezio

With the increase in users, the Warezio team experienced a problem that was affecting the entire company. Although Warezio was using E2E tests on the backend, frontend tests and manual testing, there were still bugs and logic errors in the application that were very difficult to spot before they occurred to the user. This was because the bugs only happened in very specific cases, for example with a specific group of users or on specific versions of the web browser.

The inability to catch these problems through automated testing and subsequent manual testing had the following consequences:

Account managers’ workload

Account managers who take care of individual clients had to deal with constant phone calls from Warezia’s clients demanding that they could not perform a specific task in the application. They then had to address this request with the technical team, and account managers are not technically minded and therefore the transfer of information to the technical team is not always accurate.

Growing client dissatisfaction with the app

The client was not dissatisfied because there was a problem with the application and he had to contact his account manager. He was dissatisfied because the frequent response from the Warezia team was

We can’t find the error because it’s not happening. We need more information on what exactly you were doing to find the error.

The request from Warezio was a significant burden for the client. Firstly, he no longer knew with absolute certainty exactly what he had done in the application and secondly, this type of reporting was causing an increase in distrust of the Warezio team as they were unable to fix their own bugs and was also putting a time burden on the client.

Dramatic increase in internal costs of dealing with client requests

The communication flow Client - Account Manager - Technical Department for solving bugs and errors meant an increase in internal costs for Warezio. Mainly because the client had described the bug inaccurately at the beginning and then the description was made even more inaccurate by the account manager. This caused the need for further communication between all parties until the technical department was satisfied with the description enough to fix the bug.

Slowing down software development

The development plan is crucial for companies like Warezio and getting it right affects the entire current and future success of the project. Requests from bug-themed clients are unpredictable and must be addressed immediately. An unexpected number of bugs and errors can disrupt the entire plan. This situation has happened several times at Warezia, and new features that were already planned from a marketing perspective had to be postponed due to the acute resolution of all bugs.

First solution

The technical department, represented by Jan Vavřínek, the company’s CTO, realized the problem and started looking for a solution. From conversations in the programming industry, they learned about the existence of Sentry and Inspector.dev. Both tools provide a monitoring service to resolve application errors. Since Inspector.dev tool does not allow to implement monitoring in Single Page Application (separate frontend and backend), the department decided to implement Sentry tool.

The Sentry tool allows you to “replay” the screen and errors in the JavaScript console as they happened to the user. Jan’s hope in implementing the tool was that once their client called with a problem, they would be able to “replay” exactly what the client did and why the error happened. However, the Sentry tool did not meet their expectations because it is not a bug finding tool, but a bug reproduction tool. Thus, the tool only recorded application crashes, which were minimal in the sum of all bugs.

Warezio subsequently encountered other debugging tools but did not choose any solution.

Why Latta?

Latta is not a tool, but a service. It is a service that does not aim to record bugs and help you solve them. Latta’s goal is to delegate bugs in general to itself, so that the client almost forgets they exist. It becomes this service because of the following fundamental factors:

The client does not call/write

Latta receives feedback via a Latta button, which the user presses to report the error. He also adds information about what he doesn’t like about the app’s behaviour. This eliminates all the complex communication between the client, account manager and developers.

Latta records what the user did in the app

Unlike other services, Latta records what’s happening on the client’s screen much more thoroughly, even at the browser version level. The subsequent reproduction is much more accurate.

Latta fixes the bug itself without searching for it and writing code

Without the programmer having to open their IDE, Latta finds the bug, codes the fix, and pushes the code to a GitHub or GitLab repository. The amount of data Latta collects as users use the application makes AI bug fixing more accurate than ever.

Process of implementation

The development team decided to implement Latta in two projects. In its client application, where clients can check how the service is working and change its settings, and in software that searches the internet for illegal content by scraping.

Latta was added to the web application in the form of a javascript library and to the scraping backend in the form of a POST request to Latta’s API, complete with an error message if the backend crashed. The implementation from registration to running reporting and automatic bug fixes took less than 15 minutes.

Examples of Latta fixing a bug

Cannot create an episode of the series

The client wanted to register a new episode of the show so that the Warezia system could protect it. But the application showed the user the error message “Something went wrong”. So the client hit the Latta button and wrote “Could not create a new episode for my show”.

Latta first understood that the problem was on the backend side and then identified an error in the EpisodeController.php file, the createEpisode method at the point where the code checks whether the user owns the work and can therefore create an episode for it.

if(!auth('sanctum')->user()->can('manage', $work))
    return response('This work is not yours', ResponseAlias::HTTP_UNAUTHORIZED);

The code was missing the ”!” at the beginning of the condition, which caused the reverse logic, so the client could create an episode for any show except his. Latta fixed the condition by adding the ”!” character to the beginning of the condition, correcting the evaluation logic.

I didn’t receive a password reset email

The client could not log into the application and therefore decided to reset the password. He did not receive a confirmation email to reset the password. He pressed the Latta button and it said “I reset the password but nothing happened”.

Latta first understood that the problem was on the backend side and then identified the error in the PasswordController.php file, putPassword method. The programmer here forgot to send an email. Latta therefore added a command to send a password reset email in the correct place.

Mail::to([$user-email])->send(new MailPasswordRestore($user->email, $code, $user->primaryLanguage()->lang_code));

Review from Warezio on how Latta helped them

Latta has allowed us to quickly identify and fix bugs, which has greatly improved the efficiency of our development work. It gives us the peace of mind to focus on innovation instead of constantly debugging bugs that also need to be addressed immediately.

Jan Vavřínek, Warezio CTO