Yuri Kovalov’s Case for a Crowded Rehearsal

A hundred visitors arrived at a website, and the website gave way. For Yuri Kovalov, this was a useful afternoon. The visitors were virtual, the exercise was deliberate, and the people running it had never done load testing before. A failure discovered in a rehearsal comes with a privilege that a failure in front of customers rarely offers: time to think.

The exercise began with an approach from Ruslan Desyatnikov, CEO of QA Mentor. Could a manual QA team get somewhere with PFLB’s AI-assisted testing? Kovalov described a 30-minute demonstration, followed by a team working on its own. It ran a one-hour test with 100 virtual users. The target was a static site, a limitation he made explicit. Still, the team had produced a result it could see and discuss.

It is a neat introduction to a founder whose working subject is the moment software stops behaving politely. Kovalov runs PFLB from Mountain View, California. His career began with banking systems and now includes cloud testing and automated reports. Through those changes, the practical problem has stayed recognizable: how to learn something uncomfortable while there is still time to use it.

The small office came first

Kovalov dates his start in IT to 2002. Work on core banking performance optimization brought him into contact with load testing specialists whose competence impressed him. He became a performance engineer himself. By 2008, he wanted a company focused on testing and analyzing how software and IT systems performed. Performance Lab began in Moscow, with modest investment and a small technopark office.

The company had two founders. Maxim Kutuzov brought a longstanding interest in starting a business; Kovalov brought the technical specialty. In an early account of their partnership, Kovalov said he had not previously been thinking about owning a company. At first, he handled the substance of the work while Kutuzov took responsibility for sales and commercial activity. Entrepreneurship grew out of a working relationship.

That distinction gives the origin some texture. There was a discipline to practice, a team to organize, and someone willing to sell the result. The founders were building during the financial crisis of 2008. A small specialist office was an unglamorous place to begin, which is one of its charms. Banking infrastructure rarely requires a founder to be glamorous. It does require the transactions to finish.

His technical education included computer-aided design systems at the Kharkiv Aviation Institute. He also earned an MBA at the Academy of National Economy. Later came Stanford courses and certificates, including Innovation and Entrepreneurship. The combination is practical: an education in how systems are designed, followed by study of how organizations are built and developed.

Let the user do the talking

By 2016, Kovalov was introducing a different sort of test. UXCrowd let a website owner submit an address and receive a recording of someone using the site while saying what they thought. Paying customers could select respondents by characteristics such as age or income. The premise was appealingly direct: watch the person try to do the thing your website is supposed to make easy.

At the time, he described Performance Lab as a business with more than 300 people and offices in Moscow, Izhevsk, and Santa Clara. UXCrowd was a new project within a career that already had an established services business behind it. He reported about 300 tests in its first several weeks, with more than 50 testers registered. Those were early figures, belonging to that launch.

A recording catches a kind of difficulty a server chart cannot explain. Someone hesitates. A label makes little sense. The intended next step remains stubbornly obscure. There is something wonderfully efficient about asking a stranger to narrate the confusion that a product team has spent weeks learning to overlook. Familiarity is a generous editor of our own mistakes.

UXCrowd approached the person at the other end of the software from a different direction. Both kinds of testing let a product team examine what its work means for the people using it. One watches an individual encounter the interface; the other investigates what happens when a crowd encounters the system. UXCrowd gave that interest in observation a voice, literally.

A test for the person doing the testing

Kovalov’s curiosity also took him into blockchain performance. A 2019 Performance Conf program listed him speaking about DQN, a technology for testing blockchain networks. The same program included a presentation by Vladimir Kuvshinov about the cloud load testing tool boomq. Databases, protocols, scripts, and new markets shared the agenda. It was a specialist gathering, with suitably specialist problems to argue over.

A few years later, he applied a similar preference for concrete evidence to hiring. His recommendation in a June 2024 business panel was to use tests designed for the role, with prepared questions and scored answers. Generic interviews, he argued, can produce poor decisions. Here, too, he wanted the assessment to resemble the thing being assessed.

That is a small piece of advice, and small pieces often make a person more legible than a mission statement. An applicant can speak fluently about work without showing how they perform it. A website can look convincing while serving one visitor. In each setting, the practical trial adds evidence to the first impression.

The recommendation also puts people back into a story increasingly full of automation. Choosing who will investigate a result remains consequential. So does choosing the right exercise. A beautifully scored answer to a badly chosen question is still a badly chosen question, now wearing a tie.

The report has to leave the engineering team

In 2022, Kovalov launched PFLB as a Silicon Valley SaaS business offering a load testing platform. His current biography describes more than two decades in the field. The service company and the software product represent different ways of delivering that experience: people can do the work for a client, while a platform gives another team tools to carry it out.

By April 2025, the product agenda included an especially familiar piece of office labor: writing up what happened. PFLB announced AI Reports, combining automated analysis and written explanations with interactive charts. Results could be shared through a link without requiring the recipient to register. The feature addressed the journey from a completed test to a result someone else could understand.

“We built AI Reports to help engineers deliver smarter load testing results faster.”

Yuri Kovalov · April 2025

A report crosses a boundary. The engineer may want to inspect a slow transaction, while a manager needs to decide whether a release can proceed. A graph does not relieve either person of that decision. It can, however, give them something specific to discuss. Making the result readable is part of making the test useful.

That is also why the static-site qualification in the QA Mentor experiment matters. A demonstration becomes more credible when its edges are visible. Showing that newcomers can run a basic test says something worthwhile. Describing the kind of site they tested helps the next team judge whether its own problem is comparable.

The crowd gets a rehearsal

In August 2026, Kovalov published a walkthrough using Claude and PFLB’s MCP server to test a benchmark store. The business task was explicitly a fictional composite drawn from Black Friday projects; the store and measurements were real. The exercise stepped through 600, 1,200, and 2,200 virtual users, then returned to 600 to examine recovery. At the target load, checkout missed its response-time requirement. The verdict was that the store was not ready.

The return to the first load is the telling detail. Surviving the rush is one question. Resuming ordinary service afterwards is another. A rehearsal can ask both, provided someone remembers to put them in the plan. The usefulness lies in the sequence of questions, as much as in the size of the simulated crowd.

There is a certain restraint in publishing an exercise that ends with a missed requirement. The product’s role is to help reveal the result. A reassuring answer would have been less useful if the store could not meet the intended demand. The uncomfortable finding gives the team a reason to change something and run the experiment again.

Still taking the first call

For all the machinery, Kovalov’s description of his current working habits is personal. He calls himself an engineer running a QA company and says he still joins almost every discovery call. That keeps him near the point where a customer describes a problem before it has been reduced to a test plan or a purchase.

His interests outside work include travel and business books. The latter appeared in his early founder conversation too, when he brought up something he had been reading during a discussion of disclosing company figures. Business learning has been part of the account for years, alongside the technical work.

The next question in his career is how much of the specialist’s craft can be made available to a team approaching it for the first time. The answer is being worked out in scripts, reports, demonstrations, and customer conversations. The first hundred imaginary visitors offered one useful answer. They arrived early enough for somebody to learn from the trouble.