When you enter the world of systems and software development today, these are the two paths set down for you – build and buy. And whenever you are tasked with the inclusion of in-app chat, this question will always arise. There are multiple ways with which this match between build and buy can be settled. In fact, a lot of seasoned developers and industry leaders can and have declared the winner already.
When building an application from scratch or even buying an SDK, app owners need to keep some factors in mind like weighing costs, the software development life cycle, product roadmap decisions, resources required, and the risks involved.
Following is a comprehensive analysis of the feasibility of build and buy in the context of an in-app chat. We will take on this discussion from the pragmatic view of implementation of an in-app chat keeping in mind the fundamentals of software design and a very generic project roadmap for in-app chat. And through the course of each of the steps involved, we will try to pose questions that you can answer for your business and make a decision.
Let’s dive right in.
In-app chat is an integral part of any well rounded user communication plan. Not only has it time and again proved its merit as a revolutionary way of communicating with users, in-app chat is now a casual expectation from most users. And most product teams know this, that a reliable and scalable in-app chat is an absolute necessity.
Even though in-app chat is a critical baseline requirement, it is important to understand and establish the use of it according to your business’ value proposition. Simply put, what is your goal with in-app chat?
If that is your goal, by all means, development from scratch is warranted – you can start setting up an entire team and get building. However, if you are looking to provide additional or even primary support to your customers using in-app chat, in-house development is a bit of a stretch. How? Let’s get answers to these questions first, and we’ll come to the HOWs and WHYs of it later.
If the answer is, “No”, sticking to a third party, modular API and SDK solution seems most likely appropriate. However, we understand if you are still in a sort of grey area with this. Because certain businesses do have a high reliability on communication platforms like in app chat, even if in-app chat is not directly a part of the revenue stream. For example, the hospitality and travel industry indirectly depend on prime communication services to enable their business and generate revenue to a large extent. In such a case, predicting your revenue/conversions that may come from chat directly can help you to make a profitable decision.
Find Out More About: Live Chat vs In-app Messaging
Whether you build or you buy, there is a certain resource required for the sheer inclusion of in-app chat. When it comes to APIs or SDKs, this is a relatively simpler process and might not require a full fledged dev team. But that can depend on your value proposition and the nature of your business.
However, when we talk of building an application from scratch, a complete and fully functional dev team is a baseline necessity. You need a team of engineers working exclusively on building the in-app chat for a certain period of time. Because in-app chat is not just about the initial buildout, dev teams need to be on standby to refactor codes, debugging, deal with the issues that come with scalability and a lot more. When you decide to develop an in-app chat internally, you are looking at a commitment to complete the software development life cycle, including supervising, maintaining, and scaling the in-app chat.
This is what will give you the in-app chat you are looking to build internally. And preferably, you will need an experienced dev team that has built in-app chat before or a large enough training window since in-app chat might not be your dev team’s forte.
Find Out More About: 5 benefits of adding in-app chat to marketplaces
Your dev team needs to be all guns blazing for creating this in-app chat for a certain period of time. Let’s say 6 months (minimum). During this time, there will be work that will be sacrificed to build your in-app chat. And the value of that work increases with time, and might contribute to direct losses for you. As it could have enabled you to offer optimized user experiences, or counter the competition and focus on other important aspects of the business.
APIs and SDKs too come with an opportunity cost, which is generally negligible compared to in-house development. You need a support system of a few developers to deal with customization, and optimizing the user experience. Further, you might need a dev team to stabilize at the back end. But the overall opportunity cost still remains lesser.
Find Out More About: Why you need web chat for your virtual event
In most cases, financial investment is the deciding factor to choose between build and buy. Most businesses look at the initial investment required to build the in app chat and make a decision to go with seemingly cheaper APIs or SDKs. However, this seems like an obviously smart decision but there is a counter argument. And it is only fair if we explore it.
So, theoretically there is such a thing as a relative cost over time for an API. Basically, in the case of building the in-app chat from scratch the initial investment may seem a lot, but over time, it should come down. And there is a theoretical date in the future when the total costs of the recurring payments made towards the SaaS for the API or SDK will become higher, relatively.
Although, it seems to make sense in theory. But the fact remains that most businesses do not have the resources or the financial backing to take on the mammoth task of building it in-house. And even if they do, there will always be unexpected costs attached to the in house built in-app chat solution. And these make it unlikely that the SaaS recurring payments become more than the cost of building in house.
Another misconception here is that in-house built in-app chat is a one time investment. That you assign resources and money and have an eternal in-app chat solution. This is never the case, you will be rolling out finances every month towards the in-house chat solution. Much like you would for the API. Think of the maintenance costs, scalability, etc. The salary rollouts are contributing to this, even if your dev teams are handling more tasks.
So generally, this is how we look at the cost to build the in-app chat solution in-house:
Initial Cost + Maintenance Cost + Upgrading or Scaling Cost
When you take into consideration a third party API or SDK, it is a slightly different ball game. Although you don’t have to give an upfront development cost, there is a cost of implementation straight up. You will be negotiating a lot of terms with the vendor when you are looking for an in-app chat API or SDK for a decent audience size.
Of course, there will be a base price, but customizations and add-ons can quickly add up to a large amount. You need to ensure the vendor is offering you an adequate baseline design for your business. And that you’re getting a feasible solution for maintenance and scalability.
Here is how the cost of an API or SDK can be simplified:
Implementation Cost + Subscription Cost + Administrative Cost
The implementation cost covers the initial add ons, and customizations you want in addition to the base price. The subscription cost is the base price, and the premium features you choose. The administrative costs are the monitoring and supervision costs you spend via or on your employees to take care of the in-app chat operationally. It is important to note that the vendor will most likely take care of the back end and upkeep so that is not included in the administrative cost but in the subscription costs.
Over the course of time, it should take roughly about 5 years of recurring payments for an API to be equal to the upfront building costs. This is based on the average costs required to build the in house in-app chat, and the current market rate for APIs.
However, it is important to note that the in house built-in-app chat would require a capital expenditure up front, which is not preferred by financial teams. Unless you are expecting to generate revenue on it. The API or SDK in app chat requires an operational expenditure which is preferred for an in-app chat used as a communication platform for your own users.
When you build something in house, you sit through the whole ride. Your business and product are subject to market fluctuations, and you take a beating for everything when things are bad. With the ROI being such an important factor, and the unforeseen times that we are living in, speculative projects are discouraged.
The project base outline for building an in-app chat requires more time than getting an API. And even if the initial rollout time required is of no consequence to you, an important thing to consider is the impressive speed at which technology progresses.
Say you commit to creating a state of the art in app chat today, and it is taking you about 6 months. Within those 6 months, owing to the CI/CD development models in function, a competitor could be rolling out something new and impressive. Although this can be taken care of, it will require time and will definitely be a motivational setback for your project.
With an API the time to market is drastically reduced, and with a team dedicated to making the in-app chat the best ever, you get quicker rollouts for upgrades.
The app engagement and retention rates today are key decision metrics for the customer. So, one thing you can absolutely not afford is having a lazily put together in-app chat. It needs to hit the mark every time, and be as updated as possible.
Find Out More About: Chats in online communities: a logical step for better user engagement
Technology is riddled with various varieties of risk. There is the usual starting your own project, capital investment risk. But there is also a security risk. Then there is compliance. Further, performance, reliability, data storage, etc. are all looming risks that can come into the forefront at any step of the way.
Not that when you buy an API the risks magically subside, but the burden is greatly reduced. First of all, you don’t have to worry about security if you are choosing a reliable chat API like Quickblox. In fact, you can internally include an additional layer of security when you are buying an in-app chat API.
There are a few measures like encryption, authentication, user permissions, and protection at the back end that chat is subject to generally. There are compliances required for various industries like FERPA for education, HIPAA for healthcare. Of course, these are subject to local laws.
Now, maintaining a complete alert eye for security is a must for in-app chat. And implementing it is extremely tough. Even if you are building the app from scratch, you might have to seek a third party security team to create the security bubble for you. If you are already big on security, then this can be helpful in building the in-app. But if not, going for a trusted and reliable third party in-app chat solution is preferred.
However, be thorough in your research. Because with an unreliable and loose third party API you risk losing sensitive information.
Find Out More About: Building a Chat app with QuickBlox is better than building from scratch
Inline with that, is the question of data storage. If you are building an in-app chat, do you have what it takes to store and protect the data? Data presents its own set of complicated challenges, and is vulnerable to attacks. This is true even with the third party in-app chat solution. Even if you are buying an in-app chat api, is the vendor offering you a solid infrastructure for your data? Preferably cloud storage and backups?
Most vendors might be using industry standard infrastructure from third party sources. In fact, most dev teams might also be using the same infrastructure. So, the risk is generally the same with data.
APIs offer you little to no control but make it easier to eliminate all sorts of risks associated with in-app chat. Imagine if you get into a long term contract with a vendor, and they decide to completely change their service. Or if they go on a decline in the future? That poses a serious risk for your business. But, the risk of being stuck with an inadequate in house solution is still more.
Imagine if your dev team leaves, or the key developers decide to bounce. And you have an incomplete project at hand that you have put up a huge capital investment for. That’s way worse.
Although, vendor lock-ins should be avoided and the legalities of contracts be thoroughly discussed when buying a third party app. In house contracts should also be evaluated before stepping into development projects.
Find Out More About: How to Build an Instant Messaging App with Ionic and QuickBlox
This rubric offers you a comprehensive perspective of the entire project roadmap. For both building and buying. Since there is no one size fits all solution, we will refrain from answering this question in terms of this or that.
But, as per our research and feasibility analysis, the feature depth offered by chat APIs is unmatched through in-house solutions. Unless you have a dedicated dev team for in-app chat, it is highly unlikely that you will be able to keep up with the advancements if you decide to build a chat solution in house.
Find Out More About: Building a Chat app with QuickBlox is better than building from scratch