In the team-based model, we’ll attach our engineers to your existing teams or give you a specialized dedicated team. For example, if you need five iOS engineers to augment your team, that’s what we’ll do. Or you could need a whole self-managed dedicated team of web app developers. The focus of this model is to fill skill gaps in your teams.

In the product-based model, we focus on your product as a whole. All you have to do is share your software product idea, and we’ll turn it into reality from start to finish. That means we’ll have product managers, UX/UI designers, solution architects, and software engineers all working on your product without you needing to go elsewhere or hire internally. This model focuses on creating a profitable and impactful software product.

We are used to working with big brands such as Metaswitch (a Microsoft company), Royal Caribbean, AT&T and Asseco SEE, so we understand what high-quality and carrier grade deliverables mean.

We even developed our own software product (www.shakebugs.com) that helps big companies in their mobile development process.

The most common reason for the failure of a software project is because vendors don’t keep their promises, over-promise or just vanish in the middle of the process.

Normally right when you need them most. Our main goal is to be your long-term partner, and to grow with you. You can rely on us, rain or shine.

We are committed to long-term gigs and we are investing ourselves in those partnerships. Therefore, we work on small number of projects simultaneously. We don’t jump from client to client and we don’t over-stretch by running too many projects at once.

We stick with our long-term clients so they always get our full attention, and don’t start something if we’re not sure that we can deliver all our promises.

If we decide to take your gig, you can be sure we are totally committed.

Yes, we also do maintenance.

We see that as continuous work after the first version is published. Releasing the first version of a software product is just the beginning. Our belief is that the real work begins after launch.

So we strongly encourage you to plan your budget so you can have a dedicated team working on your project after launch (this could be in reduced capacity). This option gives you confidence that the team monitors how the project behaves in the real world and acts quickly based on the data from the field.

Also, to create a successful product, you should iterate it based on the usage analytics – your users know best what they need.

Back in 2014 we made our first production real-time chat using WebSockets.

Since then, we have moved on to ejabberd XMPP which has excellent support, both on the server and client side, making development and creating features like ‘seen’, ‘delivered’ and similar functionalities quicker and simpler.

But we don’t just use that. When working on the Fling app we actually worked directly with ProcessOne, the awesome guys who created ejabberd. They took care of the server side, while we in DECODE handled the client side. Later we also worked with Erlang Solutions XMPP platform MongooseIM and some other proprietary technologies.

As far as third-party services are concerned (where there isn’t so much room for hard-core modification) we have tried out TokBox, Twilio and Bandwidth, and used Sinch (a tool from the same category which also offers audio and video communication).

Our developers’ knowledge is at an advanced level. By working with a lot of teams on many different projects, we have got to know the widest variety of architectures and have seen the majority of patterns.

This means stepping in and getting familiar with your existing project won’t pose a problem.

We have also been engaged in some big carrier-grade projects for Tier-1 telecom operators and mobile banking solutions where we had to refactor the codebase and still keep the product free of regressions.