HR Planning Software
for International
Startup

 

The customer asked Azati to audit the existing solution in terms of general performance to create a roadmap of future improvements. Our team also increased application performance and delivered several new features.

CUSTOMER:

Our customer is a well-known international staffing agency. This agency acquired a successful startup that had won a local hackathon, and sometime later raised several dozens of euro during the second seed round.

The main idea of a startup was to create a standalone online platform where team members log spent time to help managers plan the workload. This project aimed to simplify long-term human resource planning in huge distributed teams.

Our customer hired the outsourcing team to complete the MVP, but the overall quality still dissatisfied the users. The front-end of the application was loading slowly, and it was a regular situation for the app to go down under a daily load. Due to these factors, the user base was decreasing from month to month.

OBJECTIVE:

The customer hired Azati to audit the application performance, as it is a good practice to invite someone from the side for a fresh look. The main goal of our engineer was to analyze the existing solution, provide a brief report about the state of the app, and find new ways of improvements.

When the developer entered the project, he was quite shocked. There was nothing that is considered application architecture. The existing solution spun around a mix of separate functions, which were created using several programming paradigms.

When the engineer reported the actual state of the application to the team manager, we involved more developers to create a complete report. Our team formed a list of the most critical issues which required immediate improvements.

Let’s have a look through this list.

#1

CHALLENGE #1:Bad application architecture

 

Startups are different from regular businesses as they tend to roll out the product to the market as soon as possible. People do not think about application performance at a scale from the beginning. It is a good practice to invest some money into the existing application improvements if the project is successful.

But in this case, the development team delivered new features instead of improving the existing code basis. Such an approach helps to increase user loyalty, but doing so people forget that the users won’t use the application if it does not cover their needs, especially if core features are unstable or even misfunction.

CHALLENGE #2:Outdated technology stack

 

The back-end of the application was created with Ruby on Rails, while the front-end was based on Angular.js (also known as Angular 1). As users do not interact with the back-end directly, they benchmark the performance of the whole application by interaction with the user interface.

Users won’t wait long to interact with the UI, especially if they see a blank screen. It was a catastrophic situation, as it took 18 seconds to load a page for the first time.

The main reason for such a situation is Angular.js. It is an outdated technology that was originally released nine years ago. It cannot match today’s performance guidelines.

#2
#3

CHALLENGE #3:A lack of automated tests

 

Today it is a new norm for a developer to write basic tests to ensure that a specific feature works well. These tests are helpful when the team is releasing new features, as new features may break the old ones. Basic automated tests (unit and functional) are essential for a healthy application.

The application included a huge list of complex and interconnected features; it was impossible to roll out a new functionality without critical bugs.

CHALLENGE #4:Premade package overuse

 

Ruby is famous for its ease of development. It helps to speed up software engineering as there is a considerable number of premade packages (in fact, plug-and-play modules) – known as Gems. There is a special package manager called RubyGems, the open-source community actively maintains it.

In our case, the outsourcing team relied on premade packages too much. They used complex packages to solve simple problems that can be eliminated in several lines of code or so. Such an approach leads to low back-end performance, as every gem takes extra memory to load additional code, that is not now actually required.

#4

PROCESS:

The customer wanted to hire a full-stack Ruby engineer with the relevant experience in Angular/Angular.js. As the budgets were very limited, the customer decided to cut down costs and find someone who works remotely. Azati showed proven Ruby expertise, it was a matter of time for us to join this project.

Our engineer convinced the customer to freeze the development and wait some time required for us to complete the audit. Our developer requested some help, as the application was big enough, and it was tricky to meet deadlines.

The part-time involvement of two additional engineers helped our team to understand how the solution works. The team forked the latest release and did minor improvements giving up unnecessary code and packages, simplifying some architectural choices as well. In three days, the audit was ready, and the team also compared the version with our improvements and the initial release.

Our version was about 26% faster in terms of back-end performance, and it took twice less time to render the page for the first load – 9 seconds instead of 18 seconds.

Our team prepared the report and presented the demo. –°ommunication, velocity, and proactivity impressed the customer, so he gave Azati a shot.

Since that moment, our engineers replaced the previous vendor. Our main idea was to build a transparent workflow and eliminate the existing problems in the shortest terms.

SOLUTION:

The previous vendor started developing the application as a single service – monolith architecture. This architecture is not suitable for this project, as it is extremely difficult to scale. Monolith is also resource and infrastructure dependent.

There was a case when the application went down when a new user was importing a huge dataset – as no free RAM left and the server eventually reboot. It is possible to scale the server itself – allocate more RAM and CPU cores, but it is not an option in the long term run.

The solution included several modules:

 
  • Registration and Authorization
  • Project Manager
  • Resource Planner
  • Time Manager
  • Analysis Module
  • Team Calendar
  • Personal Dashboard
  • Email Handler
  • Backup Manager
  • Server Side Renderer for Angular.js

As we cannot scale the solution horizontally, it was a huge problem for us to optimize data workflow. Many data-related operations took too much time as they relied on long chains of simple SQL queries and the data extracted from PostgreSQL required additional processing.

Our engineers optimized the code which operated with the database. Instead of SQL chains, engineers used complex queries. Such an approach reduced the number of database calls, and in many cases, speeded up the data extraction process.

The team also delivered a multilingual module which made the solution accessible for users from France and Germany.

TECHNOLOGIES:

 
 
 
 
 
 
 

SCREENSHOTS:

Results:

We can, in all seriousness, say that our engineers brought an order to this chaotic project, and it was not as easy as expected. This project shows how important it is to check the vendor before you start any common projects.

Since the beginning, the customer was not optimistic about the future of the product, but our timely assistance helped to stop the decline of the user base. That fact can already guarantee that the project has a bright future, as there are users who are satisfied by the solution.

Our engineers did a massive amount of work on the back-end:
 
  • Created reliable application architecture in terms of performance
  • Optimized general code basis and gave up doubtful patterns
  • Got rid of overused packages and ruby gems
  • Optimized SQL queries and data processing workflow
  • Created a bunch of automated tests, that cover main features of the application
We also delivered some game-changing front-end features:
 
  • Moved sort and search scripts out of front-end
  • Created the pagination for several sections
  • Simplified and optimized front-end code
  • Translated website into several European languages with i18n
  • Implemented advanced assets caching

What about numbers:

 

Initial page load nowtakes less than 3seconds, instead of 18

+600%

Back-end performance increased by 43%

+43%

The solution now consumes 20% less RAM

-20%

NOW:

After our engineers eliminated the most critical problems and delivered the required features, the customer froze the development. As the solution functions well, the customer can focus on marketing and business development.

It is also essential to collect feedback from the existing users to understand what features they do like and don’t like and create a product development roadmap.