How to report on testing

The article is based on How is the testing going by Michael Bolton.

Imagine that a Project Manager has approached you with a question “how is the testing going?”. We will let you know how and what to answer in this article.

An inexperienced tester will dive into numbers straight away, and his answer will sound like this: “Why, everything’s cool. I’ve completed 234 test cases out of 500. 16 automated tests out of 100 have gone down”. This here is a bad answer. Dry numbers with no context whatsoever do not reflect the state of the product, thus, useless. They do not help the manager decide what to do next and how the team should proceed. 

An experienced tester has to provide his team with useful information that will help assess risks correctly and set up the priorities.

How to present information?

At Fora Soft, we present the useful information in this order:

  1. Explain the state of the product. What serious problems we’ve encountered, why they are serious, and how they can affect our customers. This information helps the team understand what to deal with first
  2. Explain how the testing is going. What still needs testing, what has already been tested, what we will not test and why is that. It’s important to mention how the testing was being done, what environment was used and why. This data is mandatory to assess the risk of receiving problems in the untested product areas and correct the testing plan, should the need arise
  3. Explain why we test the way we do it. Why the tests we’ve chosen are more effective than those we haven’t. When time and resources are limited, it’s crucial that we choose the right testing areas and sort out priorities
  4. Let the team know about the problems we’ve encountered during testing. Namely, what makes testing harder, what may cause us to miss bugs, what could help us make testing faster and simpler. If your team knows about your problems, they can help you

The main task the tester has is finding problems that put the product’s value in danger and reporting on those problems to the project manager and the team. Providing this information in a timely manner allows creating a high-quality product without missing deadlines.

To catch any problem that endangers the product’s value quickly, we use test plans and test strategies. Stay tuned to find out how the plan and strategy are created!

Do you want to learn more about our processes and how we do things? Do not hesitate to contact us via our contact form! It is right here 🙂


How to estimate the server cost for a video platform

Let’s take a look at how to estimate a video streaming platform after the launch.

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. As a rule of thumb, services require way more money for the outgoing traffic than for the incoming traffic. So, we will only concentrate on the outgoing traffic here
  • Data storing – storing video conference recordings. You can store them on a rented server if there is not too much data. Otherwise, you will have to pay specifically for storing data
  • The server itself is the computer with the project. Usually, its rent costs a specific monthly amount. When one server isn’t enough because of too many users, people would use many servers instead. More on that later.

Traffic costs

Counting the traffic costs is the first task as it is one of the main expenditures on video streaming services. To complete it, one must calculate the amount of traffic that will go through our server within a chosen period of time. We will use 1 hour.

There is a convenient website to help us calculate the size of video files. How to use it? Insert the video resolution, duration, and FPS. You can compare terms such as 480p or 4k against “real” ones here.

You will see a sheet that might look difficult to understand, but it’s not true. Just search for Video File Size. This sheet has possible sizes that our video will have after using different compressing algorithms. For simplicity’s sake, we’ll use the compression YouTube uses. It is easy to realize and WebRTC video compression is close to the one we went with. The price will increase drastically if we decide to go with a lesser compression. Using more powerful compression may result in losing quality. It all depends on what our goal is. We will still be using YouTube-style compression as an example, and the amount of traffic we get in result will correspond to a one-way video stream.

For 1-on-1 chats, there will be 2 streams. If there are 1 streamer and 20 viewers – 20 streams. 2 streamers + 50 viewers – 100 streams (each of the 2 streams is sent to 50 viewers) or 102, if streamers receive streams from one another. Now, since we have the amount of traffic for a period of time, we need to multiply it by the price of our provider set. By the provider, we mean AWS, DigitalOcean, or our telecom provider if the servers are within our reach.

We only look at the outgoing traffic. That’s because the majority of providers offer either free unlimited incoming traffic or set such a low price that it’s not even worth checking here.

So, here is our traffic price. However, it’s just one third, so let’s move on to…

Price for storing data

If you don’t keep your stream recordings, feel free to skip this section, as the price that doesn’t concern storing video content is very low.

So, you need to keep video recordings on your server and you don’t know how much it will cost? Let us help you. Get the video size per one stream from the previous section and multiply it by the number of streamers. Multiply the result by the price for storing data on your server (calculate the price of HDD/SDD if that’s your private server).

So, all we have to do now is counting the price of keeping and supporting the server.

The server itself

Media server price

If the project is going to be somewhat loaded, you will have to pay for the hardware that sends out your streams. The amount of servers depends on the load, and they all have to be paid hourly. If you know the cost, perfect. If not, try adding something like $0,3 per hour (this is an average price for some Amazon EC2 category c5 servers)

Price for a reserved server

It’s more likely that your project will have at least one more central server with the main website on it. One would usually pay a fixed monthly amount for it. It’d be amazing if you knew how much your server cost. If you don’t, feel free to use the market average as of now – $30-$70 monthly. If it’s a simple landing without added functionality, $15 will probably do. However, if that’s a good website with an account room, video conference rooms list, text chat, notifications, and a stable online amount of more than 100 people daily, the server will cost more (from $50).


Take a 9-max meeting room. We’ll go with 640×480, compression algorithm equivalent to YouTube’s, 30 FPS (in the calculator this goes as 29.97), Amazon AWS c5 xlarge servers. Don’t forget to swap seconds for minutes!

Let’s calculate the traffic costs. Use the calculator and fill in the resolution and FPS. Check the result – 1 hour of a one-way video will take 639 Mb. Every user receives 8 streams from other participants. Therefore, we have 9*8=72 streams like that.

We get 46 GB per hour. Since we use Amazon, the traffic cost is $0,09-$0,01 per GB, depending on how much traffic was used up in the current month. In order to get to $0,01, we will have to use an immensely huge amount of traffic (40 TB), so we will use $0,08 for calculation. 46 GB by $0,08 is $3,68/h.

Let’s say we want to store the video; the size of 1 hour is 0,639 GB. We want to keep the video streams of all 9 people. The server will keep one video where other clips will be combined in one grid. Therefore, it will still take 0,639 GB. We use General Purpose SSD by Amazon S2. It costs $0,1 per GB, monthly! Therefore, we have to pay ~$0,06 for each hour of our videos each month they stay on our servers.

Amazon AWS c5 xlarge server costs $0,17 per hour. Add it to the traffic cost. Therefore, we get $3,85 as a cost for each hour of active meetings, and on top of that, $0,06 monthly for storing 1 hour of meetings.

If we want to imagine how much it will take us, we are going to need at least approximate numbers of streams daily and monthly.

Let’s say we have 4 hours of meetings like that in a day. Assuming there are 30 days in a month. we multiply 4 hours by $3,85 to get the service cost per day – $15,4, which we then multiply by 30 to find out the monthly cost with 4 hours of meetings daily =$462.

Let’s assume that we allow storing up to 100 hours of video. Add $6 monthly.

Amazon c5 large is our main server. It costs $45,99 when reserved.

To sum up all our approximate estimations for a month, we’ll pay $513,99.

Webinar with 2 streamers and 50 viewers

We keep the similar parameters: 640×480, compression algorithm equivalent to YouTube, 30 FPS, Amazon AWS c5 2xlarge servers.

The stream will still be 639 MB per hour. Since each streamer streams for 50 viewers, we have 100 streams – 63,9 GB per hour. The average cost of traffic stays at $0,08 per GB. 63,9 GB * $0,08 = $5,11 per hour.

We are not storing this video, but if we were, it would have been just 1 stream (we have 2 streamers, so we store them in the grid as 1 video), so it’s still 0,639 GB per hour. With the price of $0,01 for an hour, we’d get $0,05112 per month, for each hour of stored video.

The final result is $5,11 for an hour of a stream or $0,05112 per month for each hour of stored video, should we ever need that.

We’ll reserve Amazon c5 large as the main server. Its cost is still $45,99. So with the server, the cost is $1599,59.

1-on-1 video chats via p2p

We can tell from experience that one c5 large server can maintain more than 1000 simultaneous 1-on-1 video chats via p2p. We’ll be using that server. In this case, the traffic cost is minimal because we just help two users connect with each other. We don’t send any video streams through our servers. Nor does our traffic go through the server and we don’t need to calculate it. The price is negligible. We don’t store recordings, too.

The servers cost $0,17 per hour. For the insurance measures let’s imagine that we get a new server up each time we get 1000 people.

The approximate price for a month if we have up to 1000 chats every day, and they last for 8 hours. 0,17*8=$1,36 a day. Multiply that by 30 to get $40,8 a month.

The server we reserve is Amazon c5 large. With added $45,99, we have to pay $86,79 monthly.


Testing automation in iOS

According to Businessofapps, mobile apps become more and more popular. They offer more functions that are in need of testing. This is a crucial process in development. No one wants to use a lousy app that keeps crashing or working bad, right? Also, what if there’s a payment function in an app? Working with a product that can let you down when you send money somewhere isn’t a good idea.

To improve the quality of an app, we need to test it. It’s believed that the developer’s eye eventually starts swimming and they can miss some problems. So, we have testers for that. To increase the speed of testing and implement a system in it, testers automate the process.

Let’s take a look at testing automation using iOS apps as an example. Nowadays, mobile apps have way more functionality than before, so testing takes more time, too. And don’t forget that there are many kinds of iOS devices out there, which increases the time spent on testing even further! To guarantee that an app works correctly on all devices, many tests need to be done, which makes the process longer and more expensive. Testing automation is out there to deal with it because testers won’t need to check some functions manually. It’s enough to write a script and edit it from time to time. Sounds good, doesn’t it? Nothing is perfect, though, so let’s turn to the pros and cons of this method:


  • Concurrent testing on multiple devices
  • Faster testing process
  • No human factor. Sometimes, bugs might appear that are difficult to catch. Even if a tester is able to catch those, they can not always understand what the cause was. Automated testing may help with the precision of understanding
  • Testing transparency. When the testers swap, old scripts stay, and the testing process will continue as intended. Regression testing stays the same, too. If you need to change something, or if a new tester wants to check the application logic, the script will work as documentation. This is one of the main advantages


  • When iOS updates, you have to wait for the automated testing tools to update, too
  • The tester needs to have special knowledge about automated testing scripts. The company needs to teach employees to do that or hire more expensive ones

The auto testing tools have pros and cons about them. It’s difficult to find a perfect tool, and oftentimes you need to sacrifice convenience in working with a tool or with its possibilities.

When you need automated testing

Do you even need it? The answer is “yes”, if:

  • Your app has too many functions and features, and you are going to support it while adding new things along the way. Why do you need auto testing then? New functionality can conflict with the old one. For example, you’ve introduced a chat and calls broke. To find out the problem, the tester has to test the whole app manually. It takes a lot of time, and the tester is at risk of missing something else! Auto testing helps avoid that problem, as the tester won’t have to test everything after introducing each feature.  Whatever stayed the same will be checked automatically, as long as you launch them and then collect the data. It helps reduce the testing time and the development costs
  • You are going to adapt the app for each new iOS version and take advantage of new system possibilities. Every iOS update can break something within the app. Even if you never planned to update the app in the near future, it might be that you have to. In that case, automated testing will help with that. After that, you’ll understand what it was that broke and be able to solve the problem. Obviously, you wouldn’t add automated testing with this sole purpose, but they will help a great deal if they are already implemented
  • There are testers on your team that possess some knowledge of automated testing. They at least have to know some popular programming language if you go for, say, Appium. Or, they have to know Swift if your choice is XCTest / Earl Gray / KIF. Testers also need to know all the possible testing methods and needed tools. If your employees only know how to manually test apps and have no knowledge of programming languages whatsoever, you will either have to teach them or hire new ones

However, writing automated tests is programming, although you’re not writing new functions for your app but rather a program that goes through your product and checks it. It is expensive. It won’t be worth it to add automated tests if:

  • The app is small. It doesn’t have lots of functions and it is easy to test it manually. With that being said, you are not planning on adding new functions on a constant basis
  • The app is supposed to be developed and distributed within a short period of time, such as those for the World Cup-2018 or the Olympics-2014
  • The app changes frequently. The functionality is unstable. For instance, a startup that looks for its client and keeps changing the main features

Tools for automated testing in iOS

After finding out the main advantages and disadvantages of this approach, let’s take a look at the tools.


Apple developed a fully native tool that is out there only for testing iOS apps. Since it is native, external dependencies won’t be there. You develop tests in Swift or Objective-C, which helps developers and testers interact more effectively. However, developing in those languages isn’t that simple. It might be that testers will turn to developers to ask for help far too often, which will make work a bit chaotic. 

There is a test recorder, too. It records real actions with an app and creates a test out of them, but using it is actually quite hard. It isn’t very accurate and it’s best to use it as an assisting tool while developing main tests in Swift or Objective-C. XCUITest/XCTest also works in a separate stream, doesn’t read the state of an app. Therefore, delays in updating the data may lead to an impossibility of seeing requested elements.


The Framework by Google. It requires tests in Objective-C or Swift. The framework synchronizes requests, UI, and streams – that’s the advantage of it. However, EarlGray isn’t very popular because you can only test iOS apps with it. It isn’t very different from XCUITest, yet it is not native, so testers would rather use XCUITest.


KIF is a framework that has to be added to the project to use it. Objective-C or Swift are the testing languages. Its realism is its main competitive edge. KIF can simulate interaction with a user, therefore it’s very good for UI testing.

You see the iOS-only tools above but when mobile development is in question, oftentimes the developers go for both iOS and Android apps. So no wonder there are cross-platform tools for automated testing.


JavaScript is a language for tests with Detox. It can access the memory and control ongoing processes. The framework works with emulators and real devices and uses native methods right on the device. It also uses EarlGray and is considered to be really good at testing apps written in React Native, because React Native uses JavaScript, just like Detox. It allows for writing the same tests for Android and iOS.


Appium is the most popular tool nowadays. It allows testing apps regardless of the platform, type, and system version. Writing tests for each platform is possible using unified API, without transforming an app into a special, network-compatible kind. Appium doesn’t require adding to the app source code. It’s working as a separate tool. Let’s take a look at its advantages:

  • A big number of languages for tests: Java, C#, Python, Ruby. It means that Appium doesn’t only work with Objective-C or Swift, so all testers will be able to create tests
  • An app doesn’t need re-compiling or changing it for automation’s sake. It’s important because the test source code and the app source code aren’t in the same project, and they are developed separately. These two don’t depend on each other, so one can avoid many problems. For example, if somebody wrote the tests incorrectly and they don’t compile, it won’t affect the app in general
  • It is cross-platform. The testers can develop tests for iOS and Android in the same environment, in the same language. They can even re-use the code. It saves time and money
  • Wide functionality. You can launch and stop the app, check the visibility of elements on the screen, and use gestures. Simulator and real devices work with Appium

Appium has some disadvantages, too. It is essentially a superstructure over native iOS and Android drivers. The tests can break more often due to the mistakes in the superstructure code. It’s important to notice here that Appium is very popular, develops quickly, so arising problems will be likely solved in the future.


Automated tests gain popularity in mobile development. They have advantages and disadvantages. Introducing automated tests is worth it when the benefit outweighs the costs. It is not magic, it’s still development, but you’re not developing new functionality but the ways to test the old. If an app has many functions and you keep updating it, but the majority of functions stay the same with each version, take a look at automated testing. After spending money once, you will save more later on.

Testers won’t have to test everything manually with each update. You only changed the teacher’s profile, but all courses, login, payment, booking, admin dashboard have to work the way they did?  The automated tests will have to work for it then. If they didn’t, it means that your small update broke something, now you have to figure out what. If the tests went through – be happy, because the tester will only manually check the teacher’s profile instead of the whole functionality.

We took a look at the tools that enable automated testing. It’s worth saying that we didn’t talk about all the tools out there. There are still paid, unpopular solutions or solutions that are not supported by the developer anymore. Whenever you choose a tool, consider the application’s peculiarities, check if there will be an Android version of the app. Also, consider your tester team! 🙂

We at Fora Soft also use automated testing for some of our projects and find success with it. Do you want to learn more about this topic? Message us using the Contact us form!


What iOS developer should know. The hiring process at Fora Soft

In this article, we will explain how Fora Soft hires people. What an iOS developer should know and what interview stages they complete. Besides, you will also find out about how we carry out the mentoring process and how programmers progress.

Minimal hiring requirements

A developer should know:

  • OOP. This is a programming methodology based on representing a program as a combination of objects
  • Swift, Obj-C (reading the code). Swift is a programming language developed by Apple, and they use it to write programs for all their products. Obj-C is a previous language that Apple used for the apps. Even now one still can create objects with it but people mostly use Swift. However, one needs to at least read Obj-C, as older projects are written in it, and they need support
  • iOS SDK. Knowledge of main frameworks, such as UIKit (work with graphic representation), Foundation (work with network and date), AVKit (work with media), MapKit (work with maps), CoreLocation  (work with geolocation)
  • Apple Guideline. For an app to be approved for AppStore, it has to answer Apple’s requirements. Read Apple documentation to find out more
  • AutoLayout. This is a mechanism for page-making in the app, it is responsible for placing interface elements on the screen
  • Multithreading. It’s important for an app to complete many processes simultaneously. For example, to make a request into a network and show the data loader
  • SOA (REST API, Web Socket). To work with the network, one must understand its organization
  • Git. The version control system is out there to make the project work easier and make it possible to put a group effort into it. Besides, it allows keeping several versions of the same document. It’s also possible to return to earlier versions, determine who and when made a change, etc.

The selection and recruitment process

It consists of

  1. A candidate sends their CV to an HR
  2.  HR looks at the CV and calls the candidate if the CV meets the requirements
  3. HR speaks about the company and answers questions. Then an interview happens, where HR tests the candidate’s professional qualifications. The questions are related to the specific position.
  4. If the candidate answers the questions successfully, he is invited to join the next stage – a technical interview with an HR and team lead. The lead does the talking here. He asks not only about the job itself, but about the IT world as well. It’s important to know how well-rounded the candidate is. The HR then conducts an office tour
  5. We invite almost all candidates who passed Step 4 to complete a test assignment within a week
  6. The candidate sends the assignment, which the team lead reviews and sends feedback to the HR. Here the decision whether we invite the candidate to the final interview arises
  7. The CEO attends the final interview. The candidate receives some specific assignment, for example, developing a video call system. The candidate has to explain how they’d like to proceed with the task
  8. We send an offer

When I find an employee who turns out to be wrong for the job, I feel it is my fault because I made the decision to hire him.

Akio Morita, Sony founder

As you can see, Fora Soft takes the hiring process very seriously. Let’s take a look at the statistics that the HR department has provided.

JavaScript statistics (relevant for 1,5 months):

  1. 500 candidates
  2. 20% pass the phone interview – 100 people
  3. 40% pass the face-to-face interview – 40 people
  4. 30% complete the test assignment and the technical interview with the team lead – 12 people
  5. 90% pass the final interview with the CEO – 10 people


  1. 50 candidates
  2. 50% complete the phone interview – 25
  3. 20% complete the test assignment and the technical interview with the team lead – 5 people 
  4. 20% complete the final interview with the CEO – 1 person

To sum it up:

We send an offer to 10 JavaScript developers out of 500, which means 2%

We send an offer to 1 iOS developers out of 50, which is again 2%.

We just showed you the numbers. Go with any output you deem fit 🙂

Mentoring process

The mentor is responsible for:

  • Code review. The new programmer creates a separate branch for it, according to Git Flow. Upon completing the task, the new programmer makes a merge request, and the mentor checks the result. The good mentor will pay attention to the logic behind completing the task, leave their feedback, and send it back for the refinement. If the mentor is satisfied with everything, the merge into the development branch happens. Thanks to this mechanism, it’s possible to see how the new programmer progresses. Over time, the number of comments goes down, and the code immediately ends up in Develop
  • Meetings about the developer’s weak and strong suits. After some time, the mentor will form a professional portrait of the new developer, based on the code, approach to tasks, and other teammates’ feedback. As soon as the portrait is ready, the mentor and the developer talk about everything. These meetings happen quite often, approximately once a month
  • Informational basis (Q&A). The new developer can always ask a mentor for help
  • Task distribution. The mentor determines what the new programmer can do now and what is too early for them. The difficulty of assignments grows as the developer grows

How constant development happens

  • Development plan. Every developer creates the plan of the aims. What is it? We take a period of time and create goals for each month. For example, read book X, learn technology Y, watch conference Z. Upon the completion of each milestone, we put a mark. That way it’s easy to see how the developer progresses
  • A gradual increase in task difficulty. The mentor gives tasks to the developer depending on their difficulty. The good mentor will never assign something the new programmer can’t complete. Over time, the difficulty grows
  • Lectures within the company. Anybody can host a lecture. Found an interesting technology? Learn it yourself and let others know!
  • Collective meeting attendances. We keep an eye on the IT world and meet-ups in other companies. We attend those events together, and then create a short review on them


From the statistics, one can understand that we have very high requirements for candidates, and there’s a reason.

The team guarantees the high quality of Fora Soft products. First, we make hiring decisions carefully. Second, this is a culture of constant development. We keep a close eye at new colleagues and their code, help them find themselves in the company, level up their skills.

Thanks to that, our products have such high quality.

You have to love your work. To do that well, you have to enjoy your work. We at Fora Soft are driven by that desire – do things awesomely. We realize what kind of a person is and whether we pursue the same goals during interviews. We never leave a new employee to be eaten by projects. We are always close to guide, give advice, and just look after.

With all that said, our clients are always happy, which makes us happy, too. We created a cool product and made the client happy? The end-user is also happy because of what we did? That’s the goal we pursue.


Chat solutions: what to choose between Firebase, SendBird, Node.js +

People frequently come to us with a request to create a text chat. Some of them want a messenger with a chat being the main or the only function. Others need to add chat into different projects, such as telemedicine. In this article, we’ll take a look at the most popular options for chat creation.

All solutions for chats can be split into two categories:

  1. Ready-made chat platforms, such as Firechat, SendBird.

They have prepared functionality for main chat options. The developer needs to put a small effort and time to add a chat into an app or a website. But the behavior of functionality has strict borders by a platform creator, and possibilities for customization are limited.

  1. Technologies for exchanging data between client and server, such as Firebase Cloud Messaging, Node.js +

They allow building a very flexible chat solution upon them. Those technologies take time to implement but offer unlimited possibilities for customization.

All the four solutions are cross-platform, they work on the web, iOS, Android.

Firebase Cloud Messaging

Firebase Cloud Messaging is a platform for information exchange between a mobile app and a server. It’s widely used for notification send-out, and it can be used to build a chat on its foundation.


  • Free for products with up to 100 simultaneous users.
  • As a Google product, one can expect stable work when used correctly
  • With comprehensive documentation and high popularity, developers can find any answers quickly, which saves time and money
  • No need to buy an additional server, you can do everything on the Firebase server
  • Thanks to the Firestore database, the servers will automatically come into existence or be eliminated when they are not needed, which will save you a ton of money. Node.js and will make you create scaling separately
  • Data is cached by default and is available for search in chat offline


  • Difficult search inquiries are difficult or impossible to realize

For example, inquiries like “find all messages with “Hello!” that a user received last year from all users whose nicknames start with an A”.

The thing is when using Firebase Cloud Messaging, you are limited in choosing a database. It’s either Firebase Realtime Database or Firestore. 

Firebase Realtime Database is a NoSQL database, where data is stored as JSON. It has lots of advantages compared to traditional SQL databases. The possibilities for creating a new search inquiry are limited by a developer to keep productivity levels.

To deal with that problem, Google came up with the Firestore database. It’s a NoSQL database but its search and data structuring possibilities are vastly increased. However, difficult search inquiries still pose a bigger problem than those in SQL databases or NoSQL databases like MongoDB. Some of them are impossible, others will take much more time to develop.

  • Up to 200k simultaneous users in Firebase Realtime Database, up to a million in Firestore

Firebase Realtime Database is limited by 200k connections in the database. It’s roughly the same as 200k simultaneous users. Firebase developers think out of 10 million active app users there are 200k of those who would use the app at the same time.

Firestore offers up to a million users at the same moment.

  • Paid from 100 simultaneous users

When using Firestore, the cost is determined by read/write operations in the database. The more data is there, the more expensive it will be. For instance, by Firestore calculation, a small up (50k installations and 5k active users daily) the usage cost will be $12-14 a month. For a big app (10 mil installations with 1 mil active users daily), the cost will be $2951,52 monthly. There are borders within which Firestore is free to use.

With Firestore Realtime Database the cost is determined by the amount of data stored in a base and downloaded from there – approximately $5 a month for each stored gigabyte and $1 a month for each downloaded gigabyte.

Therefore an app that processes many read/write in the database operations, it will be cheaper to use Firebase Realtime Database.

The most profitable option would be to use Firebase Realtime Database for one type of data and Firestore for another.

For example, for a typical e-commerce app, operations that involve reading a list of goods will run every time a user opens the app, and the number of operations will grow as more people use it. The size of the list, however, won’t depend on the number of users. For an app like that, the most profitable option would be storing the list data in Firebase Realtime Database (to not pay for multiple read operations), and storing the user data in Firestore, as storing 1 gigabyte of data is cheaper there (source).

Using Firebase Cloud Messaging is free itself, which means that you only pay for using the database, hosting, and authentication.

  • Works slowly when searching offline

In Firestore, if there are hundreds of documents in the base, the offline search will be slower, which will worsen the UX. For instance, in a chat with a hundred channels, when you have to find one without internet access, the search will work noticeably slower.

  • The developer needs experience working with NoSQL to build a convenient and effective database structure

Firestore has a limit of 1 write operation in a second for 1 document. The document is a structural part of a Firestore database. The Firestore database consists of documents organized in a collection. The document is practically a set of “key-meaning” couples. It is actually a flexible limitation: if you go for 10 read operations at the same time once, Firestore will process them correctly. If, however, you keep sending thousands of requests into the base at a rate of more than 1 per second, Firestore will return errors for some requests.


Firechat is a framework for chat creation, and it was made by the Firebase team using Firebase as a foundation. Firechat uses Firebase for authorization, sync, storing data. Firechat provides API for a chat, that allows user authentication; forwarding messages, images, and files; group chats creation, sending out invitations. Here are the links to their official website and project code.


  • Saving time and money on developing

A ready-made API for the chat main functionality allows not to create a realization of those functions by yourself

  • Same advantages as with the Firebase Cloud Messaging


  • Not all functions are possible to realize

If you use a ready-made API for the chat functionality, you can only realize the functions in offers. For instance, it doesn’t support showing unread messages, deleting messages, and has a limitation of 100 users in the chat group. The full functionality list is difficult to find, but you can get an impression by their API methods here 

  • Same disadvantages as with the Firebase Cloud Messaging

Firechat only uses Firebase Realtime Database from the box. There is no choosing a database, like in the Firebase Cloud Messaging, Firebase Realtime Database, or Firestore.


Sendbird is a ready-made chat platform. It offers a multitude of prepared features, including an indication of the number of unread messages, blocking users, and admin dashboard.


  • Many functions

Lots of features are already realized and work right away: message or file exchange, invitations, users blocking, typing indication, editing messages, automatic translation, admin dashboard, group chats for up to 100 users

  • A ready-made UI with limited customization possibilities

Creating a UI and its design isn’t necessary. Sendbird offers standard UI options, which you can use as is. You can also apply your own design on top of the standard one, changing the color and form of chat components. So, we can simply add Sendbird with default settings into our product and get a char with a default design. Then, customize some components whenever the need arises.

  • Scales automatically

You don’t need to worry about having too many users so your server doesn’t catch up to the number of requests, New servers will create themselves. Sendbird supports more than a million simultaneous users. It uses AWS.


  • You can’t realize all functions

Chat and functionality behaviors are strictly set.  A user logs in and gets access to a list of channels. They can choose an existing channel or create their own. Channels are either public or private. Users can exchange messages in either one.

This is the standard structure for the majority of chats. If you need something more exotic for your product, it will be really problematic to realize that with SendBird. Some functions are outright impossible to implement, others can take much more time than if they were created from scratch, for example, with Node.js and For example, you can’t create threads to answer a message, like in Slack.

  • Not all available functions can be realized the way you see it

SendBird provides more customization opportunities than it seems. There are serious limitations, too. For example, SendBirds allows storing additional information about any user, but not more than 5 parameters. Let’s say, those will be a name, last name, city, sex, weight, eye color. So, it is not nearly enough for dating chats

  • Not as popular as Firebase and

Popularity is an important metric when choosing a framework. The more popular a framework is, the more developers using it are out there. It helps get important resources, support, answers. If other pros and cons are equal, this will help make the development faster (and cheaper if you pay for time)

  • Price

Depends on the number of users. The base package costs $400 monthly for 5k active users. With 100k active monthly users, the price will go up to $5000. Or even $7600 if you also want automatic message translation and advanced moderation. For products with more than 100k users, the price is decided individually. There is a 30-day trial period

Node.js +

Server platform Node.js, going with the real-time data exchange library helps build a chat with unlimited customization possibilities.


  • Allows realization of any functionality

The developer has full control over all components: interface, logic, and server data and endpoint can be whatever is needed. For instance, it helps organize threads to answer chosen messages, which you can’t do in SendBird. You can implement message deleting, which is nowhere to be found in Firechat.

  • Scales

Provides an opportunity to realize automatic scalability that depends on the load. It’s possible to do on AWS and other ready-made solutions, such as Oracle. However, scalability isn’t provided right away, it has to be developed by a programmer.

  • You can choose the database type that suits your product best

For instance, if in the future product you are going to realize many difficult search inquiries, you can choose the SQL database, instead of using Firestore or Firebase Realtime Database that don’t support these functions

  • The chat works quickly

Client and server exchange messages directly, which results in fast work. When you use Firebase Cloud Messaging, the message goes from your server to Firebase server, and only from there will it travel further to the device. It’s important to mention that, though, that if there is a 0,5s delay, it’s not critical for a text chat.

  • Free to use

Open-source free solution – you don’t have to pay monthly for this technology. But please note that you have to pay for a server rent, where your product is based. However, this cost is usually way lower than that of Firebase Cloud Messaging or Firechat. We will discuss forecasting server costs in a different article.


  • Requires more time and money, as the developer creates all functions from scratch
  • Not everyone can develop the chat. You will need someone with the relevant experience

To sum it up

Ready-made platforms will give you quick results because the functionality is already there. But you are limited to those functions.

Node.js and allow creating any chat you need but each function will have to be developed from zero. It takes time and money.

What to choose?

The first thing to think about, when answering this question, is what kind of solution fits you and your company best.

  • If your chat requires a minimum base functionality, you don’t have high level of requirements to it, then Firechat or a Firebase Cloud Messaging-based solution is the way to go
  • When you expect a chat to be more advanced, take a look at SendBird. Compare monthly payments to SendBird against creating a chat from zero on Node.js and
  • If there are a lot of requirements for a chat or you need lots of customized options, Node.js and are your friends!

Why at Fora Soft we recommend Node.js +

Developing the chat functionality on Node.js + takes about 40 hours. Embedding and customizing a prepared one requires around 24-32 hours.

Ready-made chats charge you every month. It is more expensive than paying just for servers in the case of Node.js + A little increase in the development costs is usually recouped in a few months.

In exchange, they:

  • Are not bound to any limitations. They can implement any functionality in the future
  • Do not depend on third-party components that developers can just stop updating someday, and your chat will stop working.

To find out more about chat creation, do not hesitate to contact us!