Back
Development 27 Apr 2026 4 min

Numbers Never Lie

How metrics changed my approach to optimization. A real case: from 'something is slow' to a 2-3 times increase in conversion through specific data

Numbers Never Lie

Feeling is not a fact

In development, it's very easy to deceive yourself. You open a website, click, wait, and think "something is working slowly." The problem is, that's not a fact. It's a feeling. I had a specific case. I noticed that adding an item to the cart was working slowly, it was quite noticeable. I wanted to optimize it immediately. I went to the CTO. The response was simple: "until you show the numbers, we won't touch anything." The correct response. Without numbers, you're not solving the problem, you're guessing.

The difference between a feeling and measurable data

First Metrics

At that time, we didn't have any proper metrics at all: no latency, no errors, no understanding of where exactly the problem was. We started with the basics: connected Prometheus, set up Grafana, and began collecting data. Only after this did it become clear where exactly the system was lagging. Then we involved the product team and looked at the funnel: where users were dropping off and how it affected conversion. Technically, the system was working, with few errors, nothing was crashing. But the metrics showed: there was a delay, users were getting lost, money was being lost. After this, we could make decisions rather than guess. As a result, the conversion increased by 2-3 times.

What to watch

The average latency value is almost useless. It's important to look at p95 and p99, what happens with the "worst" users, because they are the ones who leave and do not make purchases. Error rate is not only 500 errors, it includes timeouts, unsuccessful operations, partial failures. And most importantly, product metrics: how the technical state of the system affects conversion and revenue. Without metrics, architecture turns into opinion: "it seems faster", "let's rewrite it", "I don't like it". This is not engineering. This is guessing.

Observability, latency, and system quality signals
A system becomes improvable only when its behavior can be measured.

Metrics and Growth

If you want to grow, you need to stop thinking only in code. At the middle level and above, you are expected not just to "write code," but to improve the system with measurable results. This means being able to set a metric, read it, link it to a problem, and propose a solution. If there are no metrics in your project, you are working blindly. Even if it seems that everything is fine.

metrics

More on this topic

Latest published materials from the same category or adjacent topics.

Learning to Befriend Someone Else's Code
Development 27 Apr 2026

Learning to Befriend Someone Else's Code

Reading someone else's code for the first time is almost always stressful. But there is an algorithm that removes the chaos and provides an entry point

Read
Boilerplate is not evil
Development 27 Apr 2026

Boilerplate is not evil

DTOs, mappers, layers, and model separation seem unnecessary when the system is small. But as the project grows, boilerplate limits the area of changes, makes the code predictable, and speeds up the team's work

Read
Microservices — One of the Most Expensive Mistakes at the Start
Development 27 Apr 2026

Microservices — One of the Most Expensive Mistakes at the Start

Why microservices are not the default architecture, but a tool for a specific problem. Two real cases: when it was a mistake and when it was justified

Read