paint-brush
Here’s How the Team Chat App Pumble Was Built: An Interview With Nikola Bosic VP of Engineeringby@pumble
742 reads
742 reads

Here’s How the Team Chat App Pumble Was Built: An Interview With Nikola Bosic VP of Engineering

by PumbleJuly 9th, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Pumble is a business messaging app built by COING — a tech unicorn company with offices in California and Europe. Pumble came to the scene just in time for the great shift to remote work, offering its users an easy solution to consequent communication challenges. Nikola Bosic, VP of Engineering in Pumble and a self-proclaimed COING native, tells us all about Pumble's humble beginnings, the biggest challenges, and the most important features of Pumble, and tips for young(er) developers.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Here’s How the Team Chat App Pumble Was Built: An Interview With Nikola Bosic VP of Engineering
Pumble HackerNoon profile picture

What is that one thing we all do every day and rarely stop to think about whether we’re doing it right? 

All of you who thought of communication were right. 

Yes, we communicate daily, in more ways than one:

  • Verbally 
  • Nonverbally 
  • Asynchronously 
  • In-person 
  • At work 
  • From home
  • Via various chat apps

That’s why today we decided to tell a story about a communication tool that helps you communicate more effectively.

Have you heard of Pumble? It’s a business messaging app built by COING — a tech unicorn company with offices in California and Europe. 

Launched in October 2020, Pumble came to the scene just in time for the great shift to remote work, offering its users an easy solution to consequent communication challenges. 

At that moment, an unbelievable 42% of the US workforce was working from home full-time. Therefore, this new communication tool came at the right time. 

But, wait — it would be best to hear this story straight from the horse’s mouth. 

What better source than Nikola Bosic, the VP of Engineering in Pumble and a self-proclaimed COING native, to tell us all about Pumble (and more):

  • How it all started (and why),
  • Crucial phases before launching the app,
  • Challenges the Pumble team faced and overcame,
  • The most important features of Pumble, and
  • Tips for young(er) developers.

Let’s see what Nikola had to say about Pumble’s humble beginnings, Inception, the biggest challenges, and a lot more. 

Nikola, first of all, I want to thank you for doing this interview. Since this is a story of Pumble, a team chat app your team built, it's only natural to start from the very beginning, i.e. from the moment an idea for such an app was born. So, why did your team decide to build your own team chat app? Aren’t there enough business chat apps out there? How did it all start? 

First of all, thank you for inviting me to share my story on the genesis of Pumble. 

Let’s rewind a couple of years in the past. Namely, at the time Pumble was starting, we (COING) already had Clockify, a successful time-tracking software. Yet, our goal was never to stop at Clockify, but to have a set of tools that would help people excel at productivity and collaboration. Our idea was to make good-quality tools with free basic features — and, if you want extra features, you can upgrade to the paid plans. 

So, after the time tracker Clockify, Pumble came along. The project management tool Plaky is the third, and there may be more.

We decided to take this step because we realized that there are not enough affordable quality business communication tools on the market. There were no good free options available. Slack, the strongest on the market at the time, has a free option — but it’s quite limited (the message history, for example). Also, the paid plans for the existing applications were expensive. 

That’s when we realized that it would be nice to have a good-quality free communication tool for teams that don’t want to pay extra for the basic chat features. 

Long story short, we decided to make our own communication tool — Pumble.

So, you realized there’s a hole in the market and capitalized on that. The next step was to form a team, I presume. So, how did you do that? Which positions were the most important for that first phase? 

We knew right away that if we want to have at least one user, we need to have good support for desktop users, and for both mobile platforms — iOS and Android. This distinguishes us from other tools, which only have a web application (and there are a lot of them). Since Pumble is a communication tool, it’s only natural that you have an iOS and Android application, as well as a web application.

This meant that, from the start, we had to create three clients simultaneously — iOS, Android, and web. Actually, we were trying to develop backend services there. So, in the beginning, there was one person for each client. 

Fun fact: when we assembled the MVP (i.e. ​​Minimum viable product), there were literally four of us on the team.

Cue 6 months later — Pumble went live, and the whole company started using it. We've been using it ever since. 

Only after our team started using it internally did we start to expand the teams along various verticals.

Luckily for us, we already had a lot of people ready. Now, we practically only make new software. Everything else is a well-oiled machine that does the work. Namely, we already had working logistics from Clockify — different teams, such as content, marketing, SEO, customer support…

All these people did the same things as for Clockify — they knew what to do and they did it. Easy peasy!

I must say, that was quick — six months for a whole new product! 

Yes, we made Pumble in exactly 6 months, and immediately released a live production version. Everyone at COING (who mostly worked on Clockify at the time) started using it, and we never went back.

Six months — it really was like that.

Of course, the first version was just the MVP, for our internal collaboration — but it worked.

Clearly, your MVP was spot on! However, for a product to be successful, you need a clear-cut plan for its development. Can you share with our readers what phases you should go through before launching such an app? 

Well, it’s simple. You just need to follow a few steps: 

  1. First, you need to define a problem — you have to know the problem you’re solving. We knew what we were solving because COING is a remote team. Since we used various communication software, we knew what they lacked and what we needed. Therefore, it was not an issue for us to identify the problem — we knew exactly what we wanted to solve. The same was for Clockify. We knew what problem we were trying to solve because we knew what bothered us in the time tracking software we were using before.
  2. Then, you should know roughly how to solve the problem you’ve identified. 
  3. After that, you need to define a clear MVP.
  4. Lastly, you have to have a lot of support from the very start. It’s not enough to just have a product — it must be covered by marketing, SEO, and excellent customer support. All these things are important.

Why? 

Well, for starters, people need to be able to find your product — that’s why you need social media presence. When you hear about a product and go to their LinkedIn page or Instagram profile, and you see that they have two followers and one employee on LinkedIn, you ask yourself, "What is this, some kind of a joke?"

Secondly, when someone has a problem, you have to offer them some support.

In the end, you also have to have some tutorials, help pages, and knowledge base pages published, so that people know how to use your product. All this gives your product credibility.

After we had done all the above-mentioned, we launched Pumble — in October 2020. 

In August 2021, we introduced the Pro plan and a new Android version. 

December 2021 was also important in the development of Pumble because that’s when we integrated it with Clockify. 

In April 2022, we introduced one-on-one video and voice calls. 

The future is bright — we have a lot of other plans for Pumble.

All of that sounds simple enough — but I presume it’s not only fun and games. On that note, which Pumble feature would you single out as the most challenging for development? 

The thing is, communication applications have to be very smart and interactive. It would be a disaster if you didn’t receive a message someone had sent you. It could cause your business to fail. That’s why it’s so important for users to have reliable software.

Everything must be so robust that no mistake can be made.

If the product is not reliable, you will not use it because you cannot count on it.

In a nutshell, we have a great responsibility towards customers. That is the biggest challenge — making the software reliable for the customers counting on us.

That's it — that's a long-term problem. It's something we're constantly working on, fixing stuff, and making improvements. 

I understand — that would be a communication breakdown, and the whole application revolves around communication.

Yes, everything else can stop working — but if the communication channel fails, we have a real problem.

You cannot simply press F5, and make Pumble work again — because you don’t know it’s not working. You’re just not getting the messages (and you don’t even know somebody sent you a message in the first place).

In the beginning, if a problem occurred with Pumble (in the early stages of an app, this happens from time to time), we had no way to discuss how to fix that problem (the problem being that Pumble doesn't work) — because we communicate through Pumble. It was a little like Inception.

We are now working remotely — and successfully using Pumble within the team, so our hard work on making the app reliable is paying off.

So, what was the hardest part in the beginning? And what are the challenges you face today? Are these challenges any different from the ones before? 

Now, when we create a new feature, the main challenge is how to roll it out and make it work on all platforms (Android, iOS, and the web). The synchronization of all that is key.

We’ve already built all the important features, and they work. Now all that's left is fine-tuning them, which takes a lot of effort. We try to improve the user experience in every possible way.

In the beginning, the challenge for us was how to design a reliable system that would support millions and millions of users.

That was our initial challenge — how to design such a system — and now the challenge is how to put it into practice and make everything work the way we planned it.


From the point of view of someone who created this app, what are the primary features of your team chat app and why?

I don't know if I can call it a feature, but, as I already said, the most important thing for us is that the application is reliable. This means that:

  • You can communicate simultaneously on multiple devices, 
  • You receive messages on the phone when you sleep (if the message is important), and 
  • When you turn on the computer, you know that you will receive all the messages sent to you.

Besides this, we are currently developing video conferencing and have made a lot of progress. Now we have 1:1 audio and video calls. In my opinion, that is the biggest feature — video conferencing.

If we take into consideration the fact that, according to Fortune Business Insights, the global video conferencing market is projected to grow to $14.58 billion by 2029, the relevance of this feature is that much greater. Of course, I’m not even mentioning messaging — the core feature.

So, to sum up, the tool must be reliable.

And video conferencing will be increasingly important in the future. It already is.

Our interview is coming to an end, but I have one more question for you. Can you share some tips for younger developers, as someone who has built such a successful app? 

First and foremost, the problem you are solving must be related to you. It's okay if you have product and marketing people, but you, as a developer, have to know what you’re doing. You have to have a vision — of how to do it. Then, it's a lot easier. 

If you’re familiar with the problem you’re solving, it is much easier to anticipate, design, and facilitate adding more features later.

Even if you are not familiar with the problem, read, and investigate. You don't have to know everything a priori.

If you are solving a problem, you do not have to know in advance how to solve it — but try to read as many things as possible about it and understand the essence.

Long story short — research is key.