Aleksandr Nesterov: 'The Release Is Only the Beginning of a Mobile Product's Life'

The global mobile app market keeps expanding even though the number of new downloads has barely changed. In 2025, user spending in the App Store and Google Play reached $167 billion, up 10.6%, while the number of downloads grew by just 0.8%.

Competitive advantage is increasingly determined not by the ability to write code, but by the ability to turn that code into a product that can be developed, maintained, and kept on the market for years. We spoke with Aleksandr Nesterov, founder of NESTORE, about how to achieve that.

He went from developing the mobile services for GetTransfer and Wildberries to building his own portfolio of 12 apps. The oldest of these products has been evolving for more than seven years, and the company's user base spans dozens of countries.

We talked about when it's not worth chasing a perfect architecture, why specialists without a technical background are becoming competitors to developers, and how to build a 'cyborg' app.

The global mobile app market keeps growing, but the number of downloads has almost stopped increasing. In your view, what sets apart a product that stays on the market for years from one that quickly loses its audience?

For an app to stay in demand for years, it has to quickly deliver the solution the person installed it for. Many users decide whether to pay during onboarding itself, so the opening screens need to clearly show the service's value and lead toward a purchase.

The next challenge is retention: the product has to deliver value that makes people want to come back. Ratings matter too, and it's best to ask for them after the person has already gotten real benefit.

Good reviews, repeat use, and repeat purchases improve store rankings and increase organic traffic. If you cut free features too aggressively, weaken a core function, or respond slowly to problems, uninstalls and negative reviews start to climb.

Store rankings drop, new installs slow down, and winning the audience back later becomes much harder. So a product's long life depends on constant work on quality, retention, and user experience.

Your career has included major mobile products, including services for Wildberries and GetTransfer, and now you're building your own app portfolio. What's the main difference between corporate and indie development?

In large-scale services, the architecture has to account for the product's scale, a shared codebase, and the ability to develop as a team.

At GetTransfer, for example, the iOS team had five developers. I took part in migrating the codebase from Objective-C to Swift and worked on new features. At Wildberries, the iOS team was also around five or six people. But in your own products, many of the approaches used in large-scale development are overkill.

There, the code above all needs to be understandable and shouldn't demand unjustified amounts of time.

At the MVP stage, there's no point chasing a perfect, fully optimised architecture — it's far more important to ship the product quickly, get the first metrics, and test the hypothesis. Only once it's confirmed does it make sense to invest in more complex infrastructure and further development.

NESTORE runs 12 products: privacy and document tools, apps for self-development and habit-building, an AI Music Generator, and the game President Simulator. How do you manage work across them given how different their logic and audiences are?

The products really are quite different, and many of them grew out of my own personal needs.

For example, I needed a good scanner with convenient document storage, so I built Fill & E-Sign. I needed a reliable way to store private photos, so I created the Private Photo Vault. I wanted to experiment with my own music, so the AI Music Generator came about.

I'd long wanted to make a game, which is how President Simulator happened. It matters to me that I, or someone close to me, actually use the product myself, because that makes it possible to get feedback quickly.

But beyond that, personal experience alone isn't enough: I look at audience behaviour, and I use that data to decide what to change in the product.

Whatever has already proven effective, I try to reuse. But the same approach doesn't work everywhere, so I run A/B tests, especially for onboarding and the paywall, since that's the stage where a large share of payment decisions gets made.

I try to consolidate user support across the different products — for example, I direct users to bots through which I handle communication. That said, each product genuinely has its own audience and its own commercial results.

In 2025, for instance, Cleaner was downloaded around 37,000 times: about 7,000 downloads came from Vietnam, 4,000 each from Nigeria, India, and Italy, and around 3,400 from the US. Over that same period, the app generated about $25,000 in profit.

Folder got around 25,000 downloads and roughly $10,000 in profit, with the US and Russia among its largest markets.

One of your company's principles is 'ship, learn, and fix.' How does that cycle work in practice? You have products that have been around for years — Cleaner launched in 2020, and your speed-reading app back in 2019. What signals tell you it's time to change something in them?

It all starts with the metrics. After a release, I look at how users move through the core scenarios, where they drop off, and where problems come up.

Say, in the app for storing private photos, there's a multi-step onboarding flow, and the target action is uploading photos to a protected folder. If only 70% of users get there, that means I need to find the cause: change the copy, the interface elements, the order of the screens, and test different variants.

The same principle applies over the long run. Over a few years, mobile platforms, store requirements, and development tools all change, and some technical decisions become outdated. So older products need to be regularly revisited and refactored.

Speed Reading, for example, I originally built for myself rather than as a commercial project. Since 2019, users have installed the app around 65,000 times and updated it about 300,000 times.

Roughly once every year or two, I go back to the outdated parts of the product and rework them. I call it my 'cyborg' app: it's gone through the whole journey with me, from junior developer to product owner, and it's been changing along with me the entire time.

Your portfolio includes utilities for working with files, documents, and private data, alongside something brand new like the AI Music Generator. How is building and running an AI product technically different from building a regular mobile app?

The main difference is the backend. Most ordinary utilities can run almost entirely on the device. In an AI product, the server infrastructure becomes part of the core function itself: requests to the models and result processing all go through it.

Scaling is a separate challenge. If 100,000 users show up at once, the infrastructure has to handle that load, so I keep an eye on it and add capacity when needed.

There's also a fundamental difference in cost structure. A regular utility, once built, may require almost no additional computing cost per new user.

In an AI product, every generation costs money, so audience growth directly drives up expenses. On top of that, you have to moderate both user requests and the model's output, and I use AI tools for that too.

Your company's entire app lineup is built and maintained by a team of five. How do you organise the work so people can keep up with releases, monitoring, and technical support across a dozen products?

We don't work on all 12 products at once — I set priorities and decide what the team should focus on. I assess when it's worth investing in an existing app's development, when to launch a new idea, and when to drop a product that hasn't lived up to expectations.

If an app isn't generating revenue and shows no real prospects, I don't see the point in keeping it in the portfolio: even with minimal upkeep, it still eats up time and attention. We automate part of the work, and that's especially noticeable in testing: AI can quickly write large numbers of automated tests.

That said, it still needs oversight from a specialist, because the model sometimes writes a test that's technically there but doesn't actually check the functionality that matters.

In practice, we ship an update for at least one app roughly once a week. But release frequency isn't the goal in itself; what matters more is that an update doesn't introduce regressions and doesn't force us right back into the same product because of new bugs.

You're already using AI to test, ship, and support your products. If these tools keep making development cheaper and building an app becomes much easier, what will mobile product creators end up competing on?

I think the barrier to entry really will drop a lot, and competition will get fiercer. Already, one person with AI tools can often do what used to require an entire team. Because of that, mobile products will increasingly be built by specialists with no technical background but deep knowledge of their industry and audience.

That's a major shift for developers: technical expertise alone won't be enough anymore.

At the same time, an advantage will go to those who've worked in their niche for a long time and know their audience well. Over the years, they build up data on user behaviour, understand their needs better, and notice sooner what needs to change in the product.

It will increasingly come down not to the ability to write complex code, but to knowing your audience and being able to turn that knowledge into a working product faster than your competitors.