Why We Have To Know The Number of Active Users In Your App

When clients initially come to us, some of the first questions they hear is: “How many people do you expect to be using your app in the first month?”. Or “How many are likely to be using it simultaneously?”

Many people answer reluctantly and uncertainly, ranging from “why do you need it” to “you’re developers, you know better”. Meanwhile, the exact answer can save the client money, and quite a lot of it, actually. Sometimes even help earn it..

Is it possible to save money or even make more by answering this question?

Now, let’s talk money since we want business to be profiable, right? Information about the number of users not only helps your project team, but also helps you save or get more money. How?

By knowing how many people will use the platform, we can:

• Calculate the necessary server capacity: the client won’t have to overpay for unused resources;
• Build a scaling system architecture
• Estimate the costs of load-testing
• Build a development plan that will allow the project to go to market (or present a new version to users) as quickly as possible.

So, what we’re doing here? We’re saving money by eliminating unnecessary costs now and planning the implementation of new features in the future.

Also, this helps to make money by ensuring a quicker TTM (time-to-market). And provide the confidence that the platform is meeting its goals.

What exactly are we asking?

Depending on the specifics of the platform, it’s important for us to know:

• The maximum number of platform users per month;
• The maximum number of users on the platform online at one time;
• What exactly are users doing on the platform: e.g., posting stuff, making calls, logging in to the game — how many times a day?
• The perceived dynamics of audience growth

What if I really don’t know?

If your project is already live, chances are there are analytics out there. Google Analytics or its counterparts allow you to estimate the number of users quickly and accurately.

If not, you can rely on more technical data: information from databases, server load statistics, or summaries from the cloud provider console, and so on.

If you need our team to create a project from scratch, it makes sense to look at competitors’ statistics, for example, using the service SimilarWeb. If for some reason this is not possible, rely on 1000 active users – our experience suggests that it’s enough in the first months of the life of the product.

And, of course, in both cases you should consult our analysts. We’ll help you gather the necessary data and draw conclusions.

Is this important for all projects?

Yes, for all of them. It’s especially critical for systems that meet at least one of these criteria:

• Large inbound/outbound traffic: users uploading and downloading HD video, video conferencing for 3+ users,
• There is a requirement to ensure minimal latency: users are playing an online game, rehearsing musical instruments over a video call, or mixing a DJ set,
• The application involves long and resource-intensive operations: compressing, converting or processing video, archiving files, routing video/audio calls, processing or generating data with neural networks.

Why not make it with the expectation of many thousands and very intense online at once and for everyone?

Firstly, a platform like that will get into production later.

If we know that only a small audience (usually called early adopters) will be using it in the first months, it is more reasonable and profitable not to postpone the launch until the balancing and scaling systems are ready and tested under load.

Secondly, the larger the estimated load, the more expensive the system operation gets. Especially if it runs in the cloud. Focusing on big online means not only being able to scale, but having enough spare capacity here and now to handle a significant influx of users at any given time. That is, to keep a large and expensive server always on, not a small cheap one.

Thirdly, this calculation isn’t applicable to all projects at all.

For closed corporate platforms, it simply makes no sense to develop a product for an army of thousands of users.

What does the developer do with this data?

The developer will understand:

• What kind of server you need: on-premise, cloud (AWS, Hetzner, Google Cloud, AliCloud), or a whole network of servers
• Whether it is possible and necessary to transfer some of the load to the user device (client)
• Which of the optimization and performance-related tasks need to be implemented immediately and which can be deferred to later sprints

Offtopic: what is the difference between server load and client load?

A simple example: let’s say we’re doing our own instagram. The user shoots a video, adds simple effects, and posts the result on their feed.

If the goal is to get to the first audience quickly and economically, the pilot build can do almost everything on the server.

Pros:

• There’s no risk of getting bogged down by platform-specific limitations: video formats, load limits, and other nuances don’t bother us. Everything is handled centrally, so you can quickly make a product for all platforms and release it simultaneously
• There are no strict requirements for client devices: it’s easier to enter growing markets, such as Africa, SEA, Latin America. Even a super cheap phone, of which there are many in the mentioned regions, can do it
• Our “non-Instagram” applications for certain platforms, such as web and mobile OS, are very simple. Authorization, feed, download button, and that’s it.

And if the goal is to give full functionality to a large active audience at once, heavy server calculations lose appeal: it makes sense to harness the power of client devices immediately.

Pros:

• Fewer servers and operating costs for the same number of users
• The user feels that the application is more responsive. In addition, if there are already a lot of clients and we have added complex new features, the responsiveness of the platform will not become lower
• Users feel more comfortable experimenting with new functionality: it’s implemented on the client, so delays are minimal
• Internet may not be required during content processing – it saves traffic
• The uploaded video is published faster: it does not need to be queued for server processing
• The easier and faster the individual operations on the server, the easier and cheaper it is to scale the server. It’s especially critical when there is a sudden influx of new users

A compromise, which often turns out to be the best option – the one that doesn’t shift the whole load on one of the parties. For example, video processing tasks, such as applying effects or graphics, are often performed on the client, while the conversion of mobile video into the required formats and resolutions is performed on the server. And in this case, the distribution of tasks between the client device and the server also depends on the planned scope.

What if we develop just a component for a live project?

In the case of extending an already existing product, it’s necessary to find out where tasks are currently processed: on the device or on the server.

Then, based on the purpose of the future component and the forecast of the number of users and their activity on the platform after it appears, the developer will understand whether to improve the current architecture or migrate to a more efficient one.

So in the end, why are we asking about the number of users?

It all comes down to efficiency and saving your resources and money. We need to have as accurate knowledge as possible about the product’s scope and workload. It will help your project team to better plan the launch, allocate costs, and make the system more reliable in the long run.