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,
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.
Want to consult about your project? Request a quote and we will get back to you shortly.
Many of our customers come up to us asking if we could make an MVP for them. Yep. Even big corporate clients want what used to be a startup fad — and what is now an industry standard.
But what is an MVP? The abbreviation, standing for Minimal Viable Product, is used to imply you hit the market before you’re done with all the features. Why is it that popular then? Is it a fancy way of saying “whatever works is fine”, a bargain solution for low-budget projects… or a misused football term after all?
What is an MVP?
Speaking of minimal viable products, let’s get started with setting on the viability criteria. For a software piece, viability definition may lie within the range of “not crashing on launch” to “being able to compete against the leaders”.
Within the Lean Production Methodology, where the MVP concept originated, V stands for “bringing value to the user”. That’s why they often read MVP as Minimal Valuable Product.
The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction, and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers
Frank Robinson, the author of the term
So, MVP is basically a killer feature, and the simplest buttons and handles one might need to make use of it. You cut all the bells and whistles off your concept, strip it of all the fancy design extras, and anything that is not crucial – as simple as that.
Why would you go for an MVP?
Here’s an example. Imagine you’re a fan of a particular sport — let’s say, boxing. And you want to become the new Muhammad Ali. So, you start training with all the passion and dedication and whatever else you may find in movies about Rocky Balboa. The question is: when will you take on your first fight?
Option one. You train for ages until you feel like you are two hundred percent fit and ready.
Option two. You get some pretty basic training and jump into the ring as soon the coach is sure you’ll make it to the last round without kicking the bucket. As soon as you are viable for the ring.
Option one is tempting: if things go well, you’ll plow through the underdogs and face the big guys without losing your breath. Option two appears hurtful: if things go well, you will win. But should you win or should you lose, you won’t leave without a bruise.
However, there is a but. “If things go well” is the critical part in both scenarios. Once you enter the ring, reality comes at you fast. What if you figure out you missed something in your training? What if those in the ring are still trained better? What if the blows you receive hurt too much (shocker!)? Or – why not – what if what you deemed boxing and your passion was actually wrestling, so all your great punching skills are totally inapplicable? You’d better know that in three months than in ten years after you put your gloves on for the first time.
So, MVP is a reality check done the quickest and the cheapest way. It’s not actually cutting functions, but ensuring they are needed before you spend time and money on those.
Reality check and real checks
The MVP-centric approach grows popular as marketing skills become commonplace for entrepreneurs, no matter which is their sphere. TTM is the reason for that. TTM, or Time-to-market, is one of the key metrics for a new product. Time is always money, but when the market launch countdown is ticking, every minute costs you cash in many ways.
You want to pay for what others will pay for.
With all the research and insight behind it, the great idea your new product is based on is still a hypothesis until proven. It’s not like you already know the market craves your product, but you assume it is. There are no other means to make this hypothesis a fact but to check it on real customers. The earlier you hit the market, the quicker the feedback is on what would make your product more desirable.
Your product might be lucrative, but before it is in the market, it earns nothing.
With all the variety of monetization models available today, your product may be able to generate revenue long before it’s done and ready. Think of World of Tanks, the videogame that earned billions while being still in beta, or of all the mobile apps that are paying back the investments made. Ad-supported or subscription-based, bought in a one-time purchase or enhanced via microtransactions, your product might add some green lines to your bank account report as soon as it can deliver any value to your clients.
And yes, while the scope is small yet, you are safer in your experimenting with monetization models per se. No matter what, your missed revenue numbers will be the least frustrating.
Think of almost every successful software product. Yes, even the hardcore enterprise one would work. They never start as a one-size-fits-all solution, but as a demanded yet simple tool designed to perform a specific task.
Take a turn before you’ll have to brake for that
Developing a complicated product before learning you have to adjust it to the market is not only about losing money on features discovered to be undemanded. The more had been done before a pivot, the more has to be done to perform one. You only have to remove seats and add panels to make a cargo van from a microbus, but should you try turning a Corvette into one, you’ll end up building it from scratch.
OK, are there any real-life MVP cases?
Telegram grew popular before it got the channels, stickers, secure calls, and bots. In the beginning, all it had was a boringly simple messenger with awesome encryption. It could do less than competitors, but it could keep your communication secure. MVP? Betcha.
SAP, the first ERP software coming into one’s mind, started from a pretty simple accounting system, which didn’t sport even 10% of what it has now. The term MVP was not even coined in by that time, but in fact, that was it – a basic solution, offering a new approach on quite a limited scope.
Zappos, the mid-2000 iconic apparel e-store began as a guy buying footwear on your demand from regular stores and sending it by mail. As simple as that.
Moreover, an MVP may prove an idea before you spend zillions on can even become a business even before you expect them to do it!
Dota and Counter-Strike, as lucrative as they are now, began as community mods for popular games (Warcraft III and Half-Life, respectively). No ginormous teams of developers, designers, and community managers, no weekly content updates or events: they offered the very basic setup needed for a new gameplay pattern. A Minimally Playable Product.
How to scope an MVP?
There is a mnemonic rule designed by Eric Rice, the author of the famous “The Lean Startup”: you take your first idea for an MVP, then cut that in half, and cut it in half again – and there you got what actually is an MVP.
For those hesitant on cutting, here’s another – not that brutal – rule of thumb we nurture here in Fora Soft. You have to ask yourself three questions.
What is your favorite part of your big idea?
What do you need to use it?
If you had only 30% of your budget, what would you make first?
You may even put your imaginary budget threshold lower than that, until what fits it retains the uniqueness of your product and the very basic usability. Once you understand that you can’t push it down anymore, you got the MVP.
If it is still a complicated task like it may be, as you definitely love your idea, you can start with MVP-izing actual projects. Try to think about what makes Instagram, Google Docs, or your favorite game what they are. Take a shot on imagining they didn’t have all the features they boast now. Where is the border between “I’d go without this feature” and “Oh, it won’t be useless anymore”. More advice on how to define an MVP scope in short time.
Quick. Cheap. Dirty?
Once you develop a vision of your product’s MVP, you start revving your engine. Time is money, so you want your Minimum Viable Precious right away.
Setting your step towards the MVP on your own is where you might run into a dilemma. On one hand, coding or testing in a rush never results in good code. On the other hand, the MVP stage is somewhat forgiving to the code quality — if it works, it works.
It’s up to you to find the balance between those, but the golden rule is: no matter how much duct tape is there under the hood, the user experience for the killer feature should be streamlined and lovely. Whatever buggy and irrelevant to the key functions should be demolished mercilessly. Whatever is crucial and buggy should be a priority.
And what if they copy it?
Well, everyone remembers the copycat cases – it happened to the MSQRD app, who’d had its minute in the limelight before every competitor got their own masks. Or Snapchat with its fading posts, which turned to be a fading fad (pun intended).
That’s the concern faced by everyone taking (or sugging taking) the MVP path. If there is a killer feature, isn’t delivering a quick-and-basic product the simplest way to unwantedly hand it to bigger competitors, who’d wrap it up in glossy paper and grab your market in no time?
The short answer is yes. It is. If your killer feature is that great, all the big companies gonna copy it. Or release their own renditions already being in development. But the first one to release is the first one to win the audience — and is able either to retain it, entering the top league (like Zoom or Miro, the COVID-era superstars whose leadership is yet to be shattered).
And even if the blue chips roll out their own, more refined solutions… Remember what happened to MSQRD? Facebook bought it. For a much bigger sum than they invested in development.
SO, WHY SHOULD I CUT FEATURES AND LAUNCH MY PRODUCT EARLY?
To check your idea and be able to refine it before there’s too much money spent;
To make the audience like your product before it is even totally complete;
To start earning before you’re done spending;
To make your product become a synonym to its killer feature.
Can Fora Soft help you with an MVP?
Most certainly! For example, we started with Vodeo as an MVP. Read what the project owner, Jesse Janson, had to say about it.
On the MVP stage, it’s not just skill but experience that matters. A developer with a massive background in a certain area (media processing, streaming, and low-latency solutions in our case) is a shortcut to an MVP. Our developers, absolute pros cut the time-to-market, as they already know solutions for typical time-guzzling problems. Please, feel free to contact us via the Contact form, and we will get back to you right away!
Are you planning on a creating video software, such as video conference, webinar, telemedicine or elearning platform? Let’s see how much you’ll have to pay monthly to maintain it.
For an easier and instant response try our server cost calculator. It’s free. For more profound understanding of the estimation, keep on reading.
In this article, we’ll explain how to estimate a video streaming platform’s infrastructure cost. We’ll start with an algorithm and finish with examples. If you don’t have technical background, you can calculate using the examples.
How much does a month of a video program cost: calculation algorithm
The combined cost is based on the cost of traffic, data storing, and the server itself.
Traffic – the information that goes through our servers. In general, it’s audio and video streams.
Data storing – storing video conference recordings.
The server itself is the computer with the project. When one server isn’t enough because of too many users, people would use many servers instead.
Traffic costs
Let’s start with the cost of traffic: with video streaming it’s more expensive than data storage and the server.
Let’s calculate how much traffic will go through our server in a certain period of time.
We don’t count incoming traffic, only outgoing. This is because most providers either provide unlimited free incoming traffic, or their prices are so low that they can be neglected.
To calculate the amount of traffic that will be consumed when streaming a video, you need to understand the size of the video file to be streamed. Let’s assume that a file of 1 gigabyte will consume 1 gigabyte of traffic.
You can use the table below.
Traffic use depending on resolution, bandwidth and overall quality
Select a resolution. The right column shows how many gigabytes will be consumed per hour when streaming video in the selected resolution. The numbers are obtained with the help of a calculator. If the table does not have the necessary values, take the data from there.
Now that we have an idea of how many gigabytes an hour of video is, we need to calculate how many times the video will be downloaded from the server.
Suppose this is a streaming service and users watch the video on the site. Then, if two people watch the video, the traffic will be spent twice: the video will be watched 1 time by each user.
For services with one streamer and 20 viewers traffic equal to the size of 20 files will be spent per hour: the video will be transferred from the server to each of the 20 viewers.
In the case of a video chat for 4 people, the video size must be multiplied by 12. 4 people in the chat and each receives 3 videos of the other interlocutors from the server.
The size of the video multiplied by the number of downloads of that video from the server. Now we have the amount of traffic that is consumed per 1 hour of time. Multiply it by price per gigabyte of traffic provided by our provider: AWS, DigitalOcean. If the servers are physically in our possession, it can even be our ISP.
Voila, we got an approximate price for traffic. But that’s not all: there are still costs for video storage and the cost of renting the server itself.
Price for storing data
If you don’t keep your stream recordings, feel free to skip this section.
Storage costs for data that doesn’t include recorded video are usually so low that they can be neglected in the approximate cost calculation. We rent a server to host the site. A disk space of a couple dozens of GB, that’s available on the server, should be enough in most cases.
But if the data exceeds a few tens of gigabytes, it’s stored in a separate storage unit. It is paid for in addition.
Examples:
An app with a huge audience, like Instagram. They need extra storage, although they don’t store video call recordings because users upload a lot of photos and videos, and there are a lot of users.
Video conferencing application for a local bank for 3 branches, they store video conferencing recordings. They do not need additional storage: the recordings are stored at the same time in such a size that the server memory capacity of their site is not exceeded.
First, let’s calculate the size of files to be stored on the server. The algorithm for calculating the size of one video file is similar to the calculations above, but it doesn’t matter how many people view the file. All that matters is how many such videos to store.
Examples:
If you store a video conference recording for 4 people, you will need space equal to 4 video files – one for each participant’s video. You can combine all the videos into one and store it in an optimized form. The size of the files on the server would be 2 or more times smaller. But this feature needs to be developed, so discuss it with your developer.
If we store videos like YouTube, one file will be stored for each video. If there is functionality to change video quality depending on the user’s internet speed, one file of each quality will be stored.
Now take the size of one video, multiply it by the number of videos to be stored.
This value is multiplied by the price of storing GB of data on your server.
If it is your own computer, you can directly calculate the cost of HDD/SSD you will need to install there.
All that remains is to calculate the cost of renting or maintaining the server itself.
The cost of server
The server is the place where the program itself is located and where user data is stored. For small projects, 1 server can be used, and where there are many users, several servers can be used.
The cost of servers strongly depends on the type of project and the number of users, but you can use the tips below as an example.
In the early stages of project development, you can get by with one server for $50 per month.
If there is video conferencing or video streaming, it is advisable to have a separate server for the media server.
If there are many conferences, you can automatically create new servers on the fly for the duration of the video conference and delete them when not needed. They have a price per hour of use. If you know that price for your server, use it. If not, you can charge about $0.3 per hour for each video conference. This is the average price for the first few Amazon EC2 c5 servers from Amazon’s September 2020 calculator.
Examples of video software monthly cost calculation
#1: Video conference for 9 people
Traffic
Let’s take the resolution 640×480 – the optimal format for video chat (4:3) – the picture is composed and the face is in the middle of the screen.
According to the table in the “Traffic Costs” section above, this is 0.11 GB per hour. This is what 1 hour of video takes one way. A total of 72 streams will be sent from the server – 8 videos for each of 9 users.
Multiply 72 by 0.11 GB, you get 7.92 GB.
Traffic on AWS costs differently depending on the amount of traffic and where clients are physically located. For our approximate calculations, an average cost of $0.09 per GB will do. Multiply 7.92 GB by $0.09 and you get $0.71 per hour.
Storing
Let’s say we want to store video conference recordings. One video will be stored on the server where all other videos will be merged.
Let’s assume the new video will have a resolution of 1280×720 (this is enough to see everything) and will take 0.88GB according to the table.
We take the General Purpose SSD from Amazon S2 from Amazon S2. It costs about $0.1 per gigabyte per month as of February 2022. Multiply the video size in GB by the cost to store one GB (0.88 * 0.1), we get ~$0.088 for each hour of video. This will have to be paid every month that our video is stored on the server.
Server
Here you can take $50 for the server for the platform itself and USD 0.30 for each hour of server rental for the video conference itself.
A server that costs $0.30 can host 5 or more conferences at the same time, but for pessimistic estimates we can assume we have only one video conference.
The total cost is
$0.71 per hour for traffic.
$0.088 per month for storage of one hour of recordings
$50 a month for the server for the site and $0.30 an hour for renting a server for the videoconference itself
$0.71 and $0.30 can be added: both prices are for each hour of an active video conference. You get $1.01 per hour of videoconferencing.
How to calculate how much a month it will cost to maintain such a chat? You need at least an approximate number of videoconferences per day/month.
Let’s say we have 4 hours of video conferences a day. Multiply 4 hours by $1.01, you get the cost per day: $4.04. Multiply the cost of daily service for 30 days, you get the cost per month: $121.20.
To store all the recordings, we would need to store 4 hours * 30 days = 120 hours of video. We will pay $0.088 * 120 = $10.56 a month.
Let’s add up all monthly costs: $121.20 + $10.56 + $50 = $181.76
#2: Webinar with 2 streamers and 50 viewers
Let’s take 720×480 resolution – a suitable option for streaming. A good balance between quality and economy.
According to the table from the section “Traffic costs” above, it’s 0.44 GB per hour. That’s what 1 hour of video takes one way. There will be 102 video streams sent from the server – 2 videos for each of 50 users and 1 video for each streamer.
We have two streamers. The server will store one video with videos of both streamers merged.
Suppose the new video will have a resolution of 1280×720 (this is enough to see everything) and according to the table will take 0.88GB.
We take the General Purpose SSD from Amazon S2. It costs about $0.1 per gigabyte per month as of February 2022. 0.88 * 0.1, we’ll pay ~$0.088 for every hour of video each month it’s stored on our server.
Server
Here we can take $50 for the server under the platform itself and $0.30 for each hour of video streaming.
In fact, a server that costs $0.3 can host more than one streaming session at a time and there may be more than 50 viewers, but for pessimistic calculations, we assume that we only have one streaming session. We will still have to use such a server for that.
Total costs
$4.04 for each hour of streaming traffic.
$0.088 per month for storage of one hour of records
$50 a month for the server under the site and $0.30 per server for each hour of streaming
$4.04 and $0.30 can be added because both prices are per streaming hour. You get $4.34 for every hour of streaming.
How do we calculate how much it will cost per month? We need at least the approximate number of streaming sessions per day or month.
Suppose we have 4 hours of streaming a day. Multiply 4 by $4.34 and you get the cost per day: $17.36. Multiply by 30 and you get the cost per month: $520.8.
To store all the recordings we will need to store 4 hours * 30 days = 120 hours of video. We will pay $0.088 * 120 = $10.56 per month.
Let’s add up all monthly costs: $520.8 + $10.56 + $50 = $581.36.
#3: 1-on-1 video chats via p2p
Traffic
In the case of p2p calls, all video goes directly between users, bypassing the server. Therefore, you don’t have to pay for traffic.
This is true when a p2p connection is technically possible to establish. It is not possible only in about 10% of cases. In those cases the connection will go through the server and not directly. So 90% of the calls will be free and 10% will have to be paid for. Let’s calculate how much exactly.
Let’s take the resolution 640×480 – the optimal format for video chat (4:3) – the picture is composite, and the face in the middle of the screen. According to the table in “Traffic costs” above, this is 0.11 GB per hour. This is what 1 hour of video takes one way.
In total 2 streams will be sent from the server – 1 video for each of 2 users.
You should pay only for 10% of calls so 1 hour of video chat will cost $0.002.
Storing
We have 2 people in the chat. There will be 1 video stored on the server where the videos of these two people are combined into one.
Let’s assume the new video will have a resolution of 1280×720 (this is enough to see everything) and will take 0.88GB according to the table.
We take the General Purpose SSD from Amazon S2. It costs about $0.1 per gigabyte per month as of February 2022. 0.88 * 0.1, we’ll pay ~$0.088 for every hour of video each month it’s stored on our server.
Server
You can take $50 for the server and not take an additional server for video streaming, as the server for $50 will be able to handle more than 1000 simultaneous p2p chats.
Total costs
$0.0002 per each hour of video chats
$0.088 per month for storage of one hour of recordings
$50 per month for a server under the site
How do I calculate how much it will cost per month? You need at least an approximate number of video chats per day/month.
Let’s suppose we have 100 chats per day.
Multiply 100 by $0.002 to get the cost per day: $0.2. Multiply by 30 to get the cost per month: $6.
To store all the recordings you would need to store 3000 hours of video. We will pay $0.088 * 3000 = $264 per month.
Add all costs per month and you get $56 without all records and $320 with all records on server.
Calculations are very rough. We give them to get at least a rough idea of the cost of running a video program: it costs about $10 or $1000 or $10,000. If, after the calculations, your business comes out to 0 – do not start it. The margin should be substantial.
Have any more questions? Contact us using the contact form and we’ll get back to you with a response ASAP!
A mobile app or a web app? If you want to grow, attract new users, and retain old ones, you will have to do both. All major video service providers have mobile and web applications. Look no further than YouTube, Zoom, Instagram, TikTok, Skype.
However, the development costs money, and the money isn’t always enough for all options. What to do, where to start? It’s difficult to answer these questions without any further information. It all comes down to what you want to do and what your plan of development is. In this article, we will explain some things about how to choose a platform and provide you with relevant statistics.
Let’s first take a look at the advantages of both options. Perhaps, it will already be enough for you to make a choice.
Advantages of a web app
Availability. A user doesn’t have to download an app from AppStore or Google Play. It’s enough to follow a link or simply google a website
Quick updates. The changes to a website go directly to a user
A big computer screen allows you to insert more information
You can choose a payment system. If you have a mobile app, you will have to pay Google Play or AppStore a 30% commission fee. On a website, you are free to choose any payment system you like, and the commission is ten times lower – 3-4%.
You can create a mobile website version. It will work on iOS and Android and cost much less than two native applications. We will compare mobile sites and apps later.
Advantages of a mobile app
Convenience. A cellphone is almost always with a user, and they can use an app any time they want.
Offline mode. Although a vast majority of apps need internet to work correctly, some developers allow an offline mode for the app. It’s impossible with a website.
Push notifications. You can launch a promotion, send an advertisement, or just remind inactive users about the app. SocialMediaToday’s research shows that push notifications are more effective than sending out emails or SMS.
An opportunity to create a mobile website version is a serious advantage when your budget is limited. By doing that, it’s possible to save money on iOS and Android apps. If, however, you think of doing that, you need to consider what you can get and what you can lose.
We get all the website advantages that we had before, plus a user can now use it anywhere where they have a phone and a cell service. It’s also worth noticing that the same development team will create a mobile version of a website. Mobile apps have some advantages, though:
Speed. They will launch and work faster. According to research conducted by Kissmetrics, 40% of users leave a website if it takes more than 3 seconds to load. It’s crucial because, according to the very same research, a loading delay in one second can lower conversion by 7%. What it means is that if your website makes $100k a day, you risk losing $2,5 mil a year.
Expanded functionality. You are free to use GPS, Bluetooth, camera, and all the platform functions in the app. It can also interact with other apps, integrate with social networks, etc.
Mobile apps are used more. Due to research by eMarketer, cellphone users spend 90% of their time on apps and only 10% of their time on websites.
With what do I start?
Although we’ve taken a look at the advantages of mobile apps and web apps, it’s still unclear as to what to go with first if the budget is limited. There’s no all-round solution, and it depends on your product type. Let’s create an algorithm using popular multimedia apps to help us with that.
Target audience
Are you creating an app for business people or just regular users? Your decision might differ based on your answer. As an example, let’s take YouTube and Zoom.
YouTube.is a service for regular people. According to official statistics, it’s being used by more than 2 billion people monthly, and 70% of them do that with a mobile app. It’s understandable. Whoever doesn’t watch YouTube nowadays? People go there on their way to work and home, on public transport, in queues, in traffic jams. The mobile app is a go-to thing for YouTube because access from anywhere is essential.
Zoom is a video conference service. It’s designed more for meetings and business calls; however, no one prohibits you from calling your mom on Zoom. But it’s the planned direction towards conferences that made Zoom to be used more on desktop computers. Judging by the official statistics, you can see that only about 10% of all registered users went into the meeting using their cellphone.
The conclusion is simple. If you expect your service to be used on a daily basis, and you want it to be accessible anywhere (Instagram, TikTok, WhatsApp), choose a mobile app. If you follow other goals, such as online conferences (Zoom, Google Meet), a web version is your pick. Your partner or employee won’t always be using the service. They will do it during a meeting.
Monetization opportunities
Do you want to sell subscriptions or goods and services? When you sell digital content inside a mobile app, Google Play or AppStore will take a 30% commission fee. Unlike websites, where the payment will be not that significant, just 3-4%. It’s important because when you start out, you count every cent.
Also, according to Atrium research, people are ready to spend more on a website rather than on mobile apps. That means that if you sell expensive subscriptions, goods, or services, it’s more likely that a user will buy it on a website.
On the other hand, Jmango’s research shows that the conversion rate (a possibility that a user will buy something again later) is higher on mobile apps.
Android vs. iOS
What to do if you need to create an app, and there is only enough budget for one of those? Let’s turn to the statistics.
According to DeviceAtlas’s research, there are more Android phones out there. But there are regions where that difference is not that substantial, and there are other regions where iOS devices prevail. The knowledge we can take from here is that our decision for a platform will be affected by the market at which the application is aimed.
For example, in Argentina, Egypt, Brazil, India, and Indonesia iOS devices aren’t popular at all. In the States, Great Britain, Sweden, and Thailand iPhone competes hard with Android phones and sometimes even ends up on top.
BusinessOfApps also reports that those who own Apple devices pay two times more in apps that those with Android. Although there are fewer iOS devices, they are more expensive and are being used by more solvent people.
DeviceAtlas statistics also show that iOS devices are popular in regions with a higher quality of life. You can see the region statistics for 2018 down below (blue is for iOS, green is for Android).
By the way, the same thing stays with mobile games industry – those with iOS pay more. Gamers from countries with a high quality of life (States, China, Japan), and 48% of the market is from America and China.
If you worry about your target audience age, don’t. Comscore reports that there is no difference in terms of age, so there is no point in diving deeper into this.
Taking everything into account, it’s safe to say that an iOS app is more attractive, and this operating system is better for a single app. iOS application will bring you more money. But it’s worth mentioning that although Apple earns more in general, things might change drastically in some countries. So, if you are looking at Europe, go with iOS. However, if the app is meant for use in a concrete country or city, gather more information, so you don’t have to kick yourself afterward.
A successful service should provide both mobile and web apps. Different platforms have different advantages and disadvantages and can attract different users. The choice is yours, and we can help you with it.
If you are not sure as to what platform to choose, feel free to contact us, and we will do our best to help you out!
Estimating IT projects is a pain. Whoever gave promises they couldn’t keep, only to work overtime just to meet the deadline they have set up for themselves?
When I started my path and tried to estimate my time spent while being a developer, I always underestimated things. Every time there would appear a job I didn’t account for. Colleagues told me to multiply my estimates by 2, 3, the number Pi. Only it didn’t help to increase the estimation accuracy, just added other problems. For example, when I had to explain where the high numbers came from.
15 years have passed since then. Over this time, I’ve estimated over 250 projects, got a lot of experience, and now I’m willing to share my thoughts on the topic.
Hopefully, this article will improve the quality of the estimations you’re giving.
Why estimate?
No more than 29% of projects end up in success, according to the research by The Standish Group, conducted in 2015. The other 71% either failed or exceeded the triple limitation system: deadline, functionality, budget.
From these statistics, we can assume that project estimation is often not what it should be. Does it mean that this process is pointless? There’s even a movement on the Internet that invites you to not estimate anything and just write a code, so that whatever happens – happens (search by #noestimates).
Not having any estimations does sound appealing, but let me give you an example. Imagine that you come to a restaurant and order a steak and a bottle of wine but there are no prices on the menu. You ask a waiter: “how much?”, and he goes, “depends on how long it takes the chef to cook. Order, please. You’ll get your food, you’ll eat it and then we’ll tell you how much it cost”.
There can also be an Agile-like option: “The chef will cook your meal, and you’ll be paying as he proceeds. Do this, please, unless you’re out of money. When you have no more money, the chef will stop cooking. The steak won’t be ready, perhaps, or it will be just reaching the state when it’s edible. If it’s not edible, though.. Sorry, it’s your problem”.
This is approximately how customers in the IT-sphere feel when they’re offered to start a job without estimations.
In the example above we’d ideally like to get an exact price for the steak. At the very least, it’d be fine if we just got a price range. This way we can check whether we want to go to this restaurant, choose a cheaper one, go get a cheeseburger or stay home and cook a salad.
Going to the restaurant without any understanding as to what to expect is not the decision that a person in the right mind will take.
I hope I could convince you that estimation is an important part of a decision making process on any project. The estimation can be as close or far from reality as possible, but it’s needed nevertheless.
Reasons for underestimation
Ignoring probability theory
Imagine the following situation. A developer is approached by a manager, and the manager would like to know how long it will take the developer to finish a task. The developer has done something like that in the past and can give the “most probable” estimation. Let it be 10 days. There’s a probability that the completion of the task will last for 12 days, but the chance is lower than that of 10 days. There’s also a chance that the task would be completed in 8 days but this probability is lower as well.
It’s often assumed that estimation for a task or a project is distributed according to the normal distribution law (read more about it here). If you show estimation distributions as a graph, you’ll get this:
X shows estimation while Y shows probabilities that the estimation will turn out to be correct and a task will consume the precise amount of time. In the center, you can see the point of the highest probability. It goes with our 10-day estimation.
The area under the curve shows a probability of 100%. It means that if we go with the most probable estimation, we’ll finish the project by the deadline with the 50% chance (the area under the graph before the 10-hour estimation is half of a figure, therefore it’s 50%). So, if we go with this principle, we’ll be able to only miss 50% of the deadlines.
This is only if the distribution of probabilities does go hand-in-hand with the normal distribution. In this case, the possibility of finishing a project earlier than a possible estimation equals to finishing it later than a possible estimation. However, it’s also normal that something goes wrong with the project, and we finish it later. Of course, a miracle can happen, and we finish earlier but what is the chance of that? In other words, the amount of negative possibilities is always higher than that of positive ones.
If we go with this idea in mind, the distribution will look like this:
For this to be easier to read, let me represent this information as a cumulative graph. It will show a possibility of finishing the project earlier than a deadline or just in time:
Turns out, if we take the “most possible” estimation in 10 days, the possibility of the task being completed in that period or earlier is less than 50%
Ignoring the current level of uncertainty
As we work on a project/task, we keep learning new information. We get feedback from the manager, designer, tester, customer, and other team members. This knowledge keeps renewing. We don’t know much about the project from the beginning, but we learn more as we go along, and we can mention exactly how long it took us once we’ve finished the project.
What we know directly affects how precise our estimation is.
Luiz Laranjeira’s (Ph.D., Associate Professor at The University of Brasilia) research also shows that the accuracy of estimating a software project depends on how clear the requirements are (Luiz Laranjeira, 1990). The clearer the requirements are – the more accurate the estimation is. Usually, the estimation isn’t clear because the uncertainty is involved in the project/task. Therefore, the only way of reducing uncertainty is by reducing it in the project/task.
Considering this research and common sense, as we decrease the uncertainty on a task/project, we increase the estimation accuracy.
This graph is here to make it easier to understand. In reality, the most possible estimation may change as uncertainty decreases.
Dependency between precise estimation and the project stage
Luiz Laranjeira went on with his research and figured out how numerically dependent estimation spread in on a project stage (level of uncertainty).
Taking optimistic, pessimistic and the most possible estimations (optimistic estimation is the earliest period of finishing the project out of all, while pessimistic is vice versa, the latest) and show how their ratios change over time, from start to finish of the project, we’ll get the following picture:
This is called a cone of uncertainty. The horizontal axis stands for the time between the start and the finish of the project. The main project stages are mentioned there. The vertical axis shows a relative margin of error in the estimation.
So, at the start of the initial concept, the most possible estimation may vary from the optimistic one by 400%. When the UI is ready, the spread of estimation goes between 0.8 and 1,25 relative to the most possible estimation.
This data can be found in the table down below:
Life-cycle stage
optimistic estimation
pessimistic estimation
Initial concept
0.25х
4х
Business requirements (agreed definition of the product)
0.5х
2х
Functional and non-functional requirements
0.67х
1.5х
User Interface
0.8х
1.25х
Thoroughly thought realization
0.9х
1.15х
Finished product
1х
1х
It’s very important to note that the cone doesn’t get narrower as time goes by. For it to narrow, one needs to manage the project and take action to lower uncertainty. If one doesn’t do that, they’ll get something like this:
The green area is called a cloud of uncertainty. The estimation is subject to major deviation up to the very end of the project.
To move on the cone to the most-right point where there’s no uncertainty, we need to create a finished product :). So, as long as the product is not ready, there will always be uncertainty, and the estimation can’t be 100% precise. However, you can affect the estimation accuracy by lowering uncertainty. With this, any action targeted at lowering uncertainty also lowers the estimation spread.
This model is used in many companies, NASA included. Some adapt it to consider volatility in requirements. You can read about that in detail in “Software Estimation: Demystifying the Black Art”.
What is a good estimation?
There are plenty of options to answer this question. However, in reality, if the estimation deviates by more than 20%, the manager doesn’t have a room for maneuver. If the estimation is somewhere around 20%, the project can be finished successfully by managing functionality, deadlines, team size, etc. It does sound logical, so let’s stop at this definition of good estimation, for example. This decision has to be taken on the organizational level. Some risk and a 40-50% deviation is OK for them; others see 10% as a lot.
So, if out estimation differs from the actual result by not more than 20%, we consider it good.
Practice. Estimating a project on various stages
Let’s imagine that a project manager has approached you and asked to estimate a function or a project.
To start with, you have to study available requirements and figure out the life-cycle stage of a project definition.
What you do next depends on the stage you’re on:
Stage 1. Initial concept
If a manager approaches you and asks how long it will take to create an app where doctors will consult patients, you are on Stage 1.
When does it make sense to make estimations on this stage?
On a pre-sale stage. When you need to realize whether it’s worth it to further discuss the project. All in all, it’s better to avoid estimations on this stage and try to lower the uncertainty as soon as possible. After that, we can move on to the next stage.
What do you need to estimate on this stage?
Actual labor time data on a similar finished project.
What tools are the most suitable for this stage?
An estimation by analogy
Estimation algorithm
Actually, estimating the project on this stage is an impossible task. You can only see how long a similar project took to launch.
For example, this is how you could put your estimation into words: “I don’t know how long this project will take as I lack data. However, project X which was similar to this one took Y time. To give at least an approximate estimation, it’s imperative to make requirements clearer”.
If there’s no data from similar projects, then lowering the uncertainty and moving to the next stage is the only way to estimate here.
How to move to the next stage?
For this to happen, the requirements must be clarified. You need to understand what the app is for and its functionality.
Ideally, one should have skills in gathering and analyzing requirements.
To improve that skill, it’s recommended to read “Software requirements” by Karl Wiegers and Joy Beatty.
To gather preliminary requirements, you might use this questionnaire:
What’s the purpose of the app? What problems will it solve?
What is the target audience? (for the task above that could be doctor, patient, administrator)
What problems will each type of users solve in the app?
What platforms is the app for?
After figuring these things out, you will have an image of the app in your head with all the necessary information. With this, we’re moving to Stage 2.
Stage 2. An agreed definition of the product
We have an understanding here, although not very detailed, about what the app will do and what won’t.
When does it make sense to make estimations on this stage?
Again, on the pre-sale stage. Right when one needs to decide whether it’s worth it to complete the task or project, whether they have enough money, whether the deadlines are affordable. You need to check if the value that the project brings is worth the resources that need to be involved.
What do you need to estimate on this stage?
Quite a few finished projects and their estimations OR huge experience in the area of development to which the project is related. These two combined would be even better!
What tools are the most suitable for this stage?
An estimation by analogy
A top-to-bottom estimation
Estimation algorithm
If there was a project like this before, the approximate estimation would be the time spent on that project.
If there is no data on projects like that, you need to split the project into the main functional units, then estimate every block according to those that were done on other projects.
For example, with the app where the doctors would consult patients, we could have got something like that:
Registration
Appointment scheduling system
Notification system
Video consultation
Feedback system
Payment system
You could estimate the “registration” block by using something similar from another project and for the “feedback system” a block from a different project.
If there are blocks that were never done before or they lack data, you can either compare the necessary labor time against other blocks or reduce uncertainty and use the estimation method from the next stage.
For example, the “feedback system” module might seem twice as difficult as the “registration” module. Therefore, for the feedback, we could get an estimation twice as high as the registration.
The method of comparing one block against the other is not exactly precise, and it’s better used in the situation where the number of the blocks that were never done isn’t higher than 20% of the blocks that do have historic data. Otherwise, it’s just a guess.
After this, we summarize estimation of all blocks, and it will be the most possible one. The optimistic and pessimistic estimations can be calculated using the coefficients appropriate for the current stage – x0,5 and x2 (check the coefficient sheet).
Ideally, you should let your manager know what’s going on, and they will have to deal with it.
If the manager can’t deal with it and asks for one, single number, there are ways to do that.
How to calculate one estimation out of three? It will be answered down below in the corresponding chapter.
How to move to the next stage?
Prepare a full list of requirements. There are quite a few documentation ways, but we’ll look into a widely used one with a User Story.
We need to understand who will be using each block and what they’ll be doing with the blocks.
For example, for the “feedback system” block we would end up with these bullet points after gathering and analyzing requirements:
A patient can check all feedback about the chosen doctor
The patient can leave feedback for the doctor after a video consultation with him
The doctor can see feedback from the patients
The doctor can leave a comment on feedback
An administrator can see all feedback
The administrator can edit any feedback
The administrator can delete feedback
You will also need to collect and write down all requirements that are not functionality-based. To do that, use this check-list:
What platforms is it for?
What operating systems need to be supported?
What do you need to integrate with?
How fast is it supposed to work?
How many users at the same time can use the tool?
Clarifying this stage will move you to the next one.
Stage 3. The requirements are gathered and analyzed
This stage has a full list of what each user can do in the system. There is also a list of non-functional requirements.
When does it make sense to make estimations on this stage?
When you need to give an approximate estimation for the project before you begin working with the Time & Materials model. The estimation of tasks from this stage can be used to prioritize some of them on the project, to plan the release dates and the whole project budget. You can also use those to control the team’s efficiency on the project.
What do you need to estimate on this stage?
The list of functional requirements
The list of non-functional requirements
What tools are the most suitable for this stage?
An estimation by analogy
A top-to-bottom estimation
Estimation algorithm
You need to decompose each task (split it into components). The smaller the components are, the more precise will the estimation be.
To do it on the best of your abilities, you need to represent everything that needs to be done on paper.
For example, for our User Story that goes like “a patient can see all feedback about the chosen doctor”, we could get something like this:
We split the task here into three parts:
Create infrastructure in the database
Create the DAL level for data samples
Create a UI where the feedback will appear
If you could, you can write down the UI functionality and approve it with whoever asks for estimation. It will eliminate lots of questions, make the estimation more precise, and be a good quality of life change.
If you want to improve your interface design skills, it’s recommended to read two books: “The Humane Interface” by Jef Raskin and “About Face. The essentials of interaction design” by Alan Cooper.
Then you need to imagine what exactly will be done for each task and estimate how long it will take. Here you have to calculate time, not guess it. You have to know what you will do to finish each subtask.
If there are tasks that take more than 8 hours, split them into subtasks.
The estimation received after having done this can be considered optimistic as it most likely uses the shortest path from point A to point B, given that we haven’t forgotten anything.
Now it’s about time we thought about things that we’ve probably missed and correct the estimation accordingly. Usually, the checklist helps here. This is an example of such a list:
Testing
Design
Test data creation
Support for different screen resolutions
…
After completing this list, we have to add the tasks we might have missed to the task list:
Go through each task and subtask and think about what could go wrong, what is missed. Oftentimes, this analysis reveals things without which you can’t end up with a best-case scenario. Add them to your estimation:
After you calculate this, too, your estimation will be even closer to the optimistic one than to the most possible one. If we take a look at the cone, the estimation will be closer to its lowest line.
The exception here might be if you’ve done a similar task before and can speak with authority that you know how it’s done and how long it takes. In that case, your estimation would be called “the most possible” and it’d go along with the 1x line on the cone. Otherwise, your estimation is optimistic.
The other two estimations can be calculated with the coefficients according to this stage: x0,67 and x1.5 (check out the coefficient table).
If you calculate the estimation from the example above, we’ll get this:
Optimistic estimation: 14 hours
The most possible estimation: 20 hours
Pessimistic estimation: 31 hours
How to move to the next stage?
By designing the UI. Creating wireframes would be the best way to go.
There are multiple programs for that but I’d recommend Balsamiq and Axure RP.
Prototyping is another huge topic that is not for this article.
Having a wireframe means that we’re on the next stage.
Stage 4. The interface is designed
We have a wireframe here as well as the full list of what each user will do in the system. We also have a list of non-functional requirements.
When does it make sense to make estimations on this stage?
To create an exact estimation by the Fixed Price model. You can also do that for everything that was mentioned in the previous stage.
What do you need to estimate on this stage?
Prepared wireframes
A list of functional requirements
A list of non-functional requirements
What tools are the most suitable for this stage?
An estimation by analogy
A top-to-bottom estimation
Estimation algorithm
The same as in the previous stage. The difference is in accuracy. Having a planned interface, you won’t have to think as much and the possibility of missing something is lower.
How to move to the next stage?
Design the app architecture and thoroughly think about the realization. We won’t check that option as it is used quite rarely. With that being said, the estimation algorithm after thinking about architecture won’t differ from one on this stage. The difference is, once again, in accuracy increase.
Retrieving one estimation from the range of estimations
If you have the three types of estimation ready, we can use the knowledge by Tom DeMarco to retrieve one estimation. In his book “Waltzing with bears” he mentioned that absolute possibility can be obtained by integrating the area under the curve (in the graph we had before). The original calculation template can be downloaded from here or from here without registration. You need to insert three numbers in the template and receive a result as a list of estimations with their corresponding probabilities.
For example, for our estimations of 14, 20, and 31 hours we’ll have something like this:
You can choose any probability you deem decent for your organization, but I’d recommend 85%,
Don’t know how to estimate? Speak up!
If you don’t know what you’re asked or how to implement the functionality you need to estimate? Let your manager know, give him an approximate estimation, if that’s possible, and suggest actions that will make the estimation more precise.
For example, if you don’t know whether the technology works to finish the task, ask for some time to create a prototype that will either confirm your estimation or show what you’ve missed. If you are not sure that the task is doable, say that from the beginning. These things need to be confirmed before you’ve put their weight on your shoulders.
It’s very important to provide a manager with this information, otherwise, he can blindly trust you and have no idea that there’s a chance of missing the deadline by 500% of the time or simply not finish the product with the technology or requirements you have.
A good manager will always be by your side. You and he are in the same boat, and sometimes his career depends on whether you’ll finish on time even more than yours.
Doubts? Don’t promise
Many organizations and developers help their projects fail by taking on responsibilities too early on the cone of uncertainty. It’s risky as the possible result jumps between 100% and 1600%.
Efficient organizations and developers postpone decision making up until the moment when the cone is narrower.
Usually, this is normal for organizations that are on the more mature CMMI module level. Their actions to make the cone narrow down are clearly stated and are followed.
You can see the quality of estimations and its increase in the projects of the U.S. Air Force when they moved to the more mature CMMI level:
There’s something to think about here. Other companies’ statistics confirm this correlation.
Even here, accuracy of the estimations can’t be achieved only with estimation methods. It’s inextricably linked to the efficiency of project management. It doesn’t depend only on developers, but also on project managers and senior management.
Conclusion
It’s nearly impossible to give an absolutely correct estimation. You can, however, affect the range in which the estimation will fluctuate. To do that, try and lower the uncertainty level on the project
Making estimation be more accurate can be achieved through splitting tasks into components. As you decompose things, you’ll think what and how you will do things in details
Use checklists to lower the possibility of missing something as you estimate
Use the uncertainty cone to understand the range where your estimation will most probably fluctuate
Always be comparing the given estimate with the time that was actually spent on a task. It will help you improve your estimation skill, understand what you’ve missed, and use it as you move further.
Useful books
There is a lot of literature on the topic but I’ll recommend the two books that must be read.
Software Estimation: Demystifying the Black Art by Steve McConnell
Waltzing With Bears: Managing Risks On Software Projects by Tom DeMarco and Timothy Lister.
