Build Vs Buy Messaging Application

Section 1: The product owner


We will build this ! We often hear this from some business owners. Though it’s very progressive thinking but one should take a practical approach while analysing of complexity of any software. We often ignore some important points while considering our thoughts.“Rome was not built in a day”. Every product goes through its own journey. Lot of thought process, deliberations, discussion, feature fights, internal meetings, customer feedback happens during this evolution phase. 

When you are developing a product for a niche market you go through very deep research. As a product manager you should  be aware of best of technology to do the specific task without compromising system architecture. At times it’s not limited to just one technology stack or just one database. A holistic approach is essential.

Second aspect is about product performance during peak load. You need a specialised team to test the product and automate test cases which can be automated and also design a policy to test highly sophisticated part of the application manually.

Finally you need a specialised skill set if you are developing something which requires deep domain knowledge.  Just for example, developing a VOIP app and A2P messaging app are two very different thing. Messaging applications are very IOPS hungry due to higher demand of TPS.

Section 2 : The solution architect.


There is difference between constructing a one bedroom kitchen and a full grown shopping mall. There is a huge difference in footfalls in both. As a solution architect one need to consider the design based on peak load, future scalability, capex on opex on cloud infrastructure. If your platform cost is very high, this will impact your overall margins and eventually effect profitability. Your goal is design something robust, scalable and cost effective.

You do not have the liberty of offering fancy reports which may eventually fail when DB size increases. Certain features can be offered on-demand, saving lot of resource, which can be dedicated towards achieving high throughput.

Section 3 : Example

A high level approach of some of the technologies used in our A2P SMSC


Database: 2 RDBMS, 1 No SQL, 1 Memchached, 1 In memory

Tech Essential: Socket, Stream, Buffer

The App: UX/UI, C#, .netcore, Angualar, Nodejs, jQuery, Bootstrap

Network Stack: Reverse Proxy, nginx, Load balancer layer 3 and layer 4, IPtables, Tcpdump

Delivery: Docker, Kubernatics

Automation: Jenkins, Ansiable

Development: JIRA, Git, Confluence, IDE

Monitoring and troubleshooting: Zabix, Wireshark

Ticketing: Mfluence

Section 4: Summary

In our recommendation, its always better to buy something which is matching 80% of your requirement and stable in its performance. Building something for your internal use will  not be very cost effective approach, because its very difficult to curate and develop highly diversified skill set and  domain expertise. Even if you build something, there was chances of failing during peak load and you will also face challenges in scaling it after certain extent.

If you want more in-depth knowledge on this topic you can skype me at hexwireless.

Thanks for reading. 

Complete A2P SMS Hubbing Solution

Enterprise grade, redundant and scalable ready to deply A2P SMSC with SS7 Sigtran
Feature Release: All new Invoicing module released
This is default text for notification bar