How Aeriva has been building performance as a product from day one

How Aeriva has been building performance as a product from day one

At Aeriva, we believe that artificial intelligence and personalization only have value when the experience is instantaneous, predictable, and reliable.

As a company built to redefine how people discover, plan, and book trips, we understand that speed is not just a technical metric—it is fundamental to traveler confidence.

Therefore, one of the recent initiatives from our engineering team was to develop an advanced structure for measuring interactivity for our mobile applications, allowing us to accurately track the moment when a screen stops being merely visible and becomes truly ready for use.

The problem we identified

In modern applications, performance issues rarely manifest as catastrophic failures.

In most cases, they appear silently:

• A button takes a few extra milliseconds to respond.
• A screen appears loaded, but does not yet accept interactions.
• Small freezes generate a sense of instability.
• The experience conveys uncertainty even when technically functional.

For the traveler, these details are relevant.

When someone opens an application to search for a hotel, check a booking, or start a trip, any delay can be interpreted as lack of reliability.

In a scenario where most of the journey happens on mobile devices, we realized that we needed to measure something closer to the user's actual perception.

The limitation of traditional metrics

Our platform already monitored several operational indicators:

• Crashes and ANRs (Application Not Responding).
• API and microservice latency.
• Distributed observability metrics.
• Execution times of specific components.
• Infrastructure and availability indicators.

These signals provided excellent visibility into system health.

But they didn't answer the most important question:

When can the traveler actually use the screen?

During the evolution of our infrastructure and artificial intelligence-based products, we realized that there was a missing metric capable of representing perceived readiness by the user.

We needed to understand:

• Are new features making the experience faster or slower?
• Are architectural changes generating real benefits?
• Are Android and iOS delivering equivalent experiences?
• Are we improving the experience or just changing the technology behind it?

Creating Native Time to Interactive (NTTI)

To answer these questions, the Aeriva engineering team developed an internal metric inspired by modern Web Vitals:

Native Time to Interactive (NTTI).

The concept is simple:

A screen is not ready when it finishes rendering.

It is ready when the user can interact with it.

We define NTTI as the time needed for all essential components visible in the first area of the screen to be fully loaded and available for interaction.

Formally:

NTTI = Last essential component loaded - Start of screen rendering

The metric represents the interval between the start of interface construction and when the traveler can effectively use it.

How we implemented it

The implementation required more than just adding timers to the application.

The project was divided into four main steps.

1. Defining what 'ready' means

Product, design, and engineering worked together to determine what truly characterizes a usable screen from the traveler's point of view.

Not every visual element is essential to initiate an interaction.

2. Selecting critical components

Each screen received a specific set of components considered indispensable for use.

This allowed the metric to reflect true readiness and not just visual completion.

3. Standardizing measurement

We ensured consistency between iOS and Android, allowing reliable comparisons even on platforms with different execution behaviors.

4. Making data trustworthy

Instrumentation without confidence does not generate decisions.

Therefore, we continuously validate data quality to ensure consistency across versions, releases, and devices.

What we learned

One of the most interesting findings was the confirmation that iOS and Android exhibit significantly different behaviors even when the interface looks identical.

On iOS, we observed challenges related to:

• Main thread contention.
• Lifecycle restrictions.
• Specific rendering behaviors.

On Android, we observed the biggest impact from:

• Device fragmentation.
• Differences between manufacturers.
• Hardware variability.

Before NTTI, these differences were often masked by aggregated averages.

After implementation, we began measuring the behavior of each platform objectively and prioritizing more accurate optimizations.

More than a metric

The most important impact was not technical.

It was cultural.

By introducing NTTI, performance became part of product decisions from the beginning of development.

Teams began to:

• Instrument everything they deliver.
• Correlating code changes with real impact on the traveler.
• Detecting regressions earlier.
• Treating performance as a product requirement, not just an optimization.

Observability ceased being a supplementary activity and became part of how we build software.

What comes next

Today, NTTI is one of the main indicators analyzed before release expansions and during validations of strategic technology initiatives.

Our goal is to evolve this approach so that significant degradation in interactivity automatically becomes a signal for investigation and validation before any rollout expansion.

We believe that exceptional experiences are built when performance, artificial intelligence, and user experience evolve together.

At Aeriva, performance is not something we adjust after the fact.

It is something we design from day one.