Behind the Walls – 4PSA Teams

In a previous article, we promised you a better insight on how we are organized internally, namely the product-oriented teams we built. So, let’s start to review the teams 🙂


This software engineering team is handling the low-level aspects of our software engineering, i.e. most of the stuff other teams need in order to develop their products. Because we are lazy, we like to keep things standardized. 😀 This means that all frameworks (with one exception) are developed at this level. If something needs to be standardized, this is where it lands. Obviously what is done at here must be extremely stable. Otherwise, it will affect the stability of the entire ecosystem. This team is also in charge with the development of our distributed database, as well as with possible modifications to the open source products that we use. Should we happen to find a bug in Nginx and it needs to be solved fast because it affects deployments, this team will handle it.



On this team, we only need the product development function. Because the customer is internal, we do not need formal sales or customer support. In reality however, the customer support function is split between the members of the team, as they have to help the other developers work with what they built.


First and foremost, Pineapple is just a code name. It’s not a great name, but it works. 😉 Pineapple is a very technical team that for the time being covers strictly software product development, but in the months to come, it will acquire other competences as well. For now, Pineapple’s customers are internal developers (namely the Apps Team), but following the official launch any developer can become its customer.

There is an important IP clause to this regard, so we cannot reveal too much, except that the team is handling the next generation Unified Communications service. It’s not exactly Unified Communications by the current definition, it’s far more interesting… Curious? 😉

The team is building a platform independent back-end that enables any resource to be manipulated in the cloud. We are using the word resource in an abstract way, but we actually mean information, communication channels and entities of any type. The back-end is accessible using REST and WebSockets and it’s built on a massively scalable, distributed architecture, capable of millions of operations per second. It is the place where Apps running on the browser, mobile or desktop, connect. Technically, there are many challenges, from the quantity of handled information to the way the system works and the functionality offered to the Apps. Pineapple also includes business logic (yes, the system has mechanisms to make business logic device independent as well). The real-time nature of the communication channels increases difficulty, as there is a huge difference between 50ms and 120ms processing time.


At present, the Apps team is very technical, but in the process of acquiring more competences. This team’s customers are end-users – they are going to use the Apps developed by the team. Our approach on the end-users functionality is to provide specialized Apps that actually satisfy specific demands rather than provide mammoth applications to meet all requirements possible.

The team is developing mainly two things: the JavaScript framework for platform independent Apps and the actual Apps. This is the only framework developed outside the Stack Team, mostly because it’s still undergoing major improvements, much related to the Apps developed. The framework will eventually go to the Stack team as well. In fact, the team handles an ecosystem designed for building Apps easily and in a way that does not require massive re-coding to make it run on a different device. This includes native Apps for mobile and desktop as well.

In the end the idea is simple – code once, deploy everywhere. So far, nothing new. PhoneGap and Titanium are projects you most probably know. Our approach however is slightly different. This team does a lot of JavaScript; they are experts in it.


The IT infrastructure where our software products run is the only child of this team. But it’s a very demanding kid. While for simplification purposes we try to use IaaS services without exception, this is not always the case for reasons related to costs, availability or performance. That’s why this team has both hardware and software abilities, ranging from networks to operating system virtualization, storage, provisioning, load balancers, etc.
This is our youngest team and in the near future it will be growing at a fast pace. Their main objective is customer satisfaction, but from a different perspective – they are looking at how fast the results have been delivered to the end-user. Of course, this involves CPU usage, memory, bandwidth, requests, but in the end the only one who can appreciate how things go is the customer.


Taking into consideration what it does and the fact that it handles the entire lifecycle of the VoipNow platform, this is functionality wise the most complex team. It covers marketing, sales, customer support, and product development. VoipNow’s popularity is increasing rapidly and this puts out various challenges for the team. In other words, we need more accurately focused marketing, better sales processes, and more efficient software development. For example, every week we receive over ten improvement requests. This makes product management quite difficult because we have to satisfy customers, but in the same time not everything needs to be included in VoipNow. It is already a pretty complex product.

Furthermore, as most of our customers provide services to their subscribers using VoipNow, they have special technical support demands. VoipNow is a mature and widely used product, with the latest version launched two weeks ago.
In the near future, VoipNow will also benefit from a lot of technological improvements performed by the Stack and Apps teams.

Team Support

Team Support handles all the functions that help our other teams meet their objectives, which means small administrative tasks or highly important stuff like getting new Clouders. The other teams are their main customers and its objective is to make them happy.

We realize that the description of each team might seem pretty brief, but if any further interest we can write dedicated articles to cover each of them in detail. The leadership team was left out for obvious reasons – its role is obvious.

As you probably have noticed, many teams are looking for new colleagues – yes, we have lots of openings. For most of them, we will also be publishing articles on this blog. Stay tuned!

Post A Reply