In-app chat has quietly revolutionized the way users communicate. Chat is now integral to daily life, building communities, connecting patients with doctors, selling products, solving customers’ problems, helping fans rally around their teams, and giving students the tools they need to learn. As consumers, we hardly even notice it. Instead, we notice when chat isn’t there.
Consumers may take the ability to send and receive messages for granted, but product teams know that those users’ expectations make reliable, scalable chat functionality a critical roadmap item. They know that hundreds of careful architectural decisions back a seamless user experience, and they know that the ability to execute those decisions at the right cost and on the right timeline can make or break a software product’s success. The first and most important decision in that chain is whether to have an engineering team develop in-app chat from scratch or to buy a modular chat solution.
With developers available in house or on retainer at a contracting firm, the opportunity to develop and own a truly custom chat or messaging solution may appeal to some organizations. On the other hand, buying an existing chat solution with an as-a-Service pricing model can save a great deal of frustration up front, but comes with its own set of risks and challenges. It’s hard to predict which approach will be more practical in terms of time and money and return the greatest long-term value.
It’s worth noting that a third option for adding chat functionality to a software product does exist. For some applications, a plug-and-play chat provider like Drift or Intercom may be sufficient, with one-size-fits-all UI features and simplified back-end integrations. These solutions are great at solving the exact problems they’re intended for, but come up short in terms of customization and adaptability for unique use cases. They’re also difficult to embed directly to create a seamless in-app chat experience. We’ll focus on comparing the other two in-app chat development options: building chat functionality completely from scratch vs. building on top of a ready-made API or SDK foundation.
We assume that most organizations considering in-house development need more flexibility than a one-size-fits-all chat window can offer. And increasingly, companies that would have defaulted to in-house development 10 years ago are exploring the benefits of a new approach that combines the best of both worlds in terms of cost, time to market, and flexibility to customize and integrate as needed. The cloud and SaaS revolutions have made building on top of a ready-made codebase more practical and cost effective than ever before. Our goal is to help companies evaluate whether building on top of an existing API or SDK as-a-Service makes sense for them or whether development from scratch would still be preferable.
With chat becoming a critical feature in products across fields as diverse as financial services, esports, live-streamed concerts and events, telehealth, online dating, sales, and customer service, we’re unable to predict the needs of each niche’s use case. The decision to build or buy in-app chat will ultimately depend on your organization’s unique requirements. Still, the baselines set forth here should provide a reliable starting point for any analysis, helping to ensure that universal factors in the decision aren’t overlooked.
Here are the high-level build vs. buy factors every product team should examine:
- Evaluate Your App’s Goals, Priorities, & Core Value Prop
- Weigh Dev Team Opportunity Cost
- Compare Costs: Estimating the Financial Investment to Build or Buy Chat
- Cost to Develop Chat Functionality In House
- Calculating Initial Chat Development Cost
- Calculating Maintenance, Improvement, & Scaling Costs
- Estimate the Cost to Buy an In-App Chat Solution
- In-App Chat as a Capital vs. Operational Expenditure
- Evaluate Time to Market & Time to Value
- Competitive Advantage & Time to Market
- Select Critical Chat Features: Best-of-Breed vs. MVP
- Core In-App Chat Features for an MVP Offering
- Advanced Chat Features
- Real-World Example: Feature Depth & Reliability with TaskRabbit
- Identify Risks Involved with Building vs. Buying Chat
- Security & Compliance
- Data & Storage Ownership
- Decision Ownership
- Scalability
- Reliability & Performance
- Technical Debt
- Cross-Platform Development
- Vendor Lock-In
- Make the Final Build vs. Buy Decision
Evaluate Your App’s Goals, Priorities, & Core Value Prop
Before committing to either build or buy chat functionality, it’s important to zoom out and consider your business’s core value proposition, appropriately prioritizing chat relative to the main problems you intend to solve for your customers. This presents a dilemma for developers of many modern apps: Although highly functional in-app chat has become a critical baseline requirement, it's rarely a key business differentiator.
And although chat may seem like a simple component of a larger product, building it can take up the same development bandwidth as an entirely new product in and of itself. On its own, reliably functioning chat requires a variety of technical components and engineering resources as part of a dedicated development plan. If chat functionality really is a key differentiator inseparable from your core value prop — if your mission is to build a genuinely new and transformative way for users to communicate, like the next WhatsApp — this could justify the cost of in-house or custom development. But if chat’s primary role is to support other key features and enhance the user experience, a modular API/SDK solution is likely more appropriate.
Another way to think about where chat belongs in a broader roadmap is to consider whether the problem it solves is internal (non-billable) or external and expected to generate revenue. If chat will primarily solve an internal problem — even if it serves to streamline business systems, increase efficiency, and thereby indirectly support revenue growth — the cost of in-house development will be harder to justify.
Compare chat to other business systems that were once commonly developed in house: Today, most companies wouldn’t consider building their own email client, HR/payroll system, project management app, or suite of office apps. Even highly customizable third-party data systems are replacing the complicated proprietary approaches of yesteryear — just look at Snowflake’s blockbuster IPO as data teams look to standardize practices and make sense of the billions of events and other data points modern apps collect. In-app chat is in a similar state of evolution: With highly functional, affordable solutions already widely available, it makes less and less sense to spend valuable development resources on reinventing the wheel.
Weigh Dev Team Opportunity Cost
Engineering resources are both costly and finite. In most situations, they return the most value when they’re focused on the core value prop and top priorities discussed above. Remember: The opportunity cost of building chat in house goes beyond the feature’s monetary cost and its time to market. If a team of developers spends, say, six months on the chat project, the opportunity cost is the other new functionality they could have built in that same timeframe. Chances are, the functionality sacrificed to build chat would be of greater value in differentiating your product from its competition, optimizing the user experience, and directly generating revenue.
Unless you already have a team of experienced, dedicated chat developers in house, this type of project will require a degree of research and learning during which new code can’t be shipped. Engineers will spend time reviewing the architecture of existing solutions, testing, and making decisions about the best approach. The results of this process may sound promising, but it takes engineers away from their core competencies to develop a technology in which they’re not experts. Another counterintuitive aspect of opportunity cost is that as development teams gain skill and efficiency, the cost in terms of what they could be developing instead effectively increases.
Even if the need for a truly custom chat solution supports the build route, an impressive degree of customization may be achievable with fewer dev resources. With an API or SDK solution, a smaller dev team skips building the foundational framework and instead focuses on nailing the front and back-end integrations with your product, its platform and support systems.
Remember, too, that the decision to develop internally comes with a perpetual commitment to monitor, maintain, and upgrade the solution. After launch, it’s common to encounter new challenges — dev teams often need to refactor their code to overcome issues with scaling, for example. Although this will require fewer dev resources than the initial buildout, there will always be a non-negligible dev opportunity cost for other projects the attending team could have prioritized instead.
Compare Costs: Estimating the Financial Investment to Build or Buy Chat
Total cost is an obvious factor in the build vs. buy decision, but different methods of calculating that cost yield dramatically varied results. If the internal cost to build chat isn’t calculated carefully, for example, unplanned expenses that emerge during development can be so significant that they would have changed the initial decision to build if they had been predicted earlier.
When we think about the cost of building over time, conventional wisdom tells us that even though in-house development may require a large financial investment up front, its costs should decrease over time. There should be a date in the future when the sum of recurring SaaS payments over the same period actually becomes higher than the total amount spent on the in-house build. After that date, the in-house build keeps getting cheaper relative to the as-a-Service solution.
Theoretical Build vs. Buy Cost Over Time
This model may make sense on paper, and for a company with plenty of cash on hand and a desire to plan many years into the future, it may point to building as the right decision. But for most organizations, the up-front cost of building software in house is higher than the monthly as-a-Service fee by an order of magnitude that renders the above model unrealistic. In many cases, the costs never even out.
After initial in-house development, a feature freeze may be required to limit costs to hosting and maintenance. Even then, unexpected costs can arise if functionality breaks due to scaling or if performance issues cause a subpar user experience. Many companies also can’t afford to develop and launch their chat solution over a long period of time and would prefer an option they can deploy quickly. Still, a methodically derived estimate of the in-house build cost is critical to the build vs. buy decision.
Cost to Develop Chat Functionality In House
Your own calculation for the time and cost to build chat in house will depend on variables like developer salaries in your area, the backgrounds and levels of expertise available on your team, and the required use case(s) and feature depth of the chat module. Still, the basic methodology for the calculation should be consistent. We’ll walk through that process and run rough estimates on the low end and the high end: one for building a very simple chat feature as fast as possible under perfect conditions, and one for building a highly complex offering with more personnel and some common challenges and roadblocks thrown in.
These build estimates both assume that development is handled by a team of experienced software engineers who work under normal conditions, do not need to balance any other significant projects or priorities, and do not encounter any unplanned setbacks during development.
Here’s the most basic version of the equation, with further considerations for each component broken out in more detail below:
Simplified In-House Build Cost =
Initial Build Cost [Development Labor + Infrastructure Over Expected Finite Time Period]
+
Maintenance & Scaling Cost [Initial Break-Fix & Customer Feedback Period as Usage Grows + Recurring Infrastructure Costs]
Calculating Initial Chat Development Cost
Initial development will likely be a period of 3-6 months of intensive coding and UI integration to produce a working chat module for launch. On the low end, let’s assume your goal is a basic live chat solution like Intercom, designed for one-on-one messaging in a sales or customer service environment. You have two reasonably skilled developers each living and working in an inexpensive location at a $100k salary, and the project takes them three months without any significant hangups. You’re looking at an initial development labor cost of $50,000.
Infrastructure-as-a-Service (IaaS) costs are notoriously difficult to predict in this type of scenario and will vary based on your app’s architecture and actual server usage, but for the sake of this rough estimate, let’s say you’re using AWS with EC2 and/or Elastic Beanstalk for computing; S3, EBS or another of their storage options, and RDS for your database, with a total cost of around $500/month. That puts initial build infrastructure costs at around $1,500 — not a lot, but not quite negligible either.
With our low-end initial build estimate now at $51,500 over 3 months, let’s look at the higher end of the spectrum. (Remember that this low-end number doesn’t account for unplanned work, trial and error, or other setbacks.)
In this more costly scenario, imagine we’re building a feature-rich team collaboration chat tool similar to Slack. Like many actual developers, the ones in this example live in the San Francisco Bay area and they’re averaging $200k in salary. This project takes six of them, with the need to support a comparable experience across different platforms like iOS, Android, and web. And with some room for setbacks and iteration, let’s say it takes six months for this team to launch an MVP. Since there aren’t any users yet, infrastructure loads are still relatively low, but to be safe, let’s bump them up to $1,000/month. We’re still estimating conservatively here, and now our higher-end initial build cost has ballooned to $606,000 over 6 months.
Calculating Maintenance, Improvement, & Scaling Costs
Now, let’s do some similar math to factor in the cost of maintaining, upgrading, and scaling our newly launched in-app chat function based on customer feedback and results over the course of its first year of service. For the low-end estimate, we’ll assume our team of two talented developers did a great job of estimating growth and architected the project to scale horizontally on infrastructure like Elastic Beanstalk. We’ll still factor in one month of one developer’s labor across the year to take care of routine break-fix issues, at a cost of $8,333, but the major cost factor here will be increased infrastructure usage. Again, this number can vary greatly, and ideally the whole setup is automated to provision and deprovision servers as needed and avoid overspending. Let’s ballpark that cost at $10,000 per month. Our additional maintenance cost for the first year of operation becomes $120,833.
To sum up, our lowest-possible estimate is now at month 15 and has cost a running total of $172,333.
On the higher side, let's assume the complexities of this more feature-rich chat function will require a greater investment to dial in during the first year after launch. We’ll ask two of our higher-paid engineers to each spend a total of two months refining it, at a total cost of $66,667 for the year. And the hypothetical good news is that all that hard work pays off and the number of monthly active chat users is through the roof — unfortunately raising those AWS infrastructure costs to $20,000 per month. This scenario puts the first year’s maintenance costs at $306,667.
Our higher-end estimate has now reached a spend of almost $1 million, or $912,667, at month 18.
After the first year live in either scenario, IaaS costs will of course recur perpetually and some degree of maintenance will still be required. And all of the costs estimated above can balloon exponentially if, for one reason or another, the first build attempt goes off the rails or doesn’t work as planned.
With the above complications in mind, the total cost of in-house development often turns out higher than initially expected. Its cost also tapers more slowly over time than expected, significantly delaying the date when the total cost to build eventually matches the total cost to buy. It can easily be 5-10 years or longer before the total cost of an in-house build becomes less than the sum of smaller SaaS payments over the same period.
Estimate the Cost to Buy an In-App Chat Solution
As with building chat, buying a ready-made or API-based solution will also involve costs that may not be obvious at first. It’s important to consider these ancillary costs as well in order to produce an accurate evaluation.
One common error is the assumption that an as-a-Service solution will have zero up-front cost. In practice, the cost of implementation can be significant, even though it’s likely to remain far lower than the cost of development from scratch. At the least, any pre-built solution will require basic UI customization to match your brand, and then it will need to be integrated with your existing app and any other relevant supporting systems. An out-of-the-box sales chatbot like Drift, for example, designed to upsell users within your UI, will still need its script and playbook optimized from time to time and will need to be synced properly with your CRM.
An API or SDK-based solution, compared to this kind of truly pre-packaged solution, will require heavier implementation work by a team of qualified developers, but will offer a much greater degree of customization. This work to integrate and customize an API-based solution, building a bridge between your app and the chat API, should still be a lot less costly than an in-house build while offering many of the same benefits. And if you don’t want to invest too many resources in customization, many API providers offer broadly applicable chat UI kits that can be deployed rapidly. Some Stream chat API customers who are satisfied with a more universal look and feel have actually been able to launch chat in the app store in just one week.
If you’re evaluating any third-party product, be sure to understand the nuances of each individual vendor’s unique pricing structure. Rapid growth in monthly active users, for example, can trigger overages. It’s important to work with the vendor to customize a plan that anticipates your needs and provides the most economical pricing structure for both the present and the future.
“Optional” features, too, can add up quickly. This is especially true when a vendor’s baseline offering is inadequate by design, with a remarkably inexpensive base price but with add-ons that are essentially required. And although a SaaS vendor covers the cost of back-end maintenance and upkeep, a purchased solution will still require monitoring and maintenance in-house as customer and business needs evolve and as integrated systems change.
Simplified SaaS TCO =
Cost of Implementation [Customization + Integration]
+
Recurring Subscription Cost [Base Rate + Anticipated Overages + Premium Features]
+
Recurring Administrative / Maintenance Labor Cost
Since most chat as-a-service solutions bill based on usage, let’s assume a relatively high number of monthly active users (MAU), constant across the hypothetical built and bought solutions. At 1,000,000 MAU, leading in-chat API providers are charging about $15,000 per month. It would take more than five years of SaaS payments to equal the higher-end up-front cost of about $1 million calculated above.
In-App Chat as a Capital Expenditure vs. an Operational Expenditure
Fueled by cloud infrastructure and widely available high-speed internet, the X-as-a-Service revolution continues to transform vendor pricing models and organizations’ internal budget structures. Many problems that once required a large up-front capital expenditure (CapEx) to solve can now be converted to lower-risk recurring operational expenditures (OpEx). This is often true for in-app chat, and the benefits go beyond simple cost savings.
When a choice is available, finance teams tend to prefer operational expenditures over capital expenditures because they’re easier to forecast and inherently less risky. Where an in-house development team may be forced to overspend to solve an unforeseen problem, a SaaS provider absorbs that risk and keeps monthly or annual billing more predictable and consistent.
The SaaS vendor also takes advantage of economies of scale, offsetting the cost of product development and upkeep with revenue from many client organizations. Enterprise-grade SaaS solutions bundle costs into one easily reported line item and often guarantee reliability and uptime with monetary SLAs. The operationalized predictability of SaaS billing makes it easier to budget and offers more agility to scale spending proportional to usage and associated revenue.
Capital expenditures, on the other hand, are inherently risky because they require large sums of cash up front without a guaranteed return. When this type of system fails or needs upgrades, it can require emergency spending that was not originally budgeted for that quarter or even that year. For many organizations exploring the build vs. buy dilemma for in-app chat, the opportunity to treat development and implementation as a predictable, scalable operational expense supports the decision to go with a third-party solution.
Evaluate In-App Chat’s Time to Market & Time to Value
When global market instability forces organizations to reassess budgets, new investments come under closer scrutiny and face increased pressure to provide returns as soon as possible. In a March 2020 interview on COVID-19’s impacts to business, for example, longtime General Electric CIO Gary Reiner offered the following insight on long-term technology investments:
“If it doesn’t pay back this year, it’s probably not going to get done.”
Unlike with speculative or nice-to-have technologies, chat statistics prove its value and ROI potential for a broad spectrum of use cases. Still, a project that can go to market quickly and offset its own costs right away will be easier to justify to finance teams, the C suite, and investors. Pre-built foundations win this comparison outright over in-house development, which will require considerably more lead time before launch, not to mention further maintenance and optimization afterward.
Using the same cost model from above, we estimate the amount of time required for a team of experienced developers to scope, develop, test, and launch a minimum viable in-app chat feature to be three months.
Competitive Advantage & Time to Market
Even if your in-app chat project isn’t affected by changing economic conditions or budget constrictions, its time to market can have a major impact on your app’s competitive advantage. Today’s CI/CD development models allow for incredibly short feedback cycles and rapid deployment of new features. Those incremental code pushes add up, meaning a competitor could make impressive progress in the time it would take to ship just V1 of a chat feature. With an API or SDK-based solution, a small team can have chat live in just a few weeks, as opposed to the 3-6 month build process outlined above.
Given the number of apps available to today’s end users, key success metrics like app engagement and retention can make or break an app in a matter of weeks or months. As more and more users expect highly functional chat as a basic requirement, every day without it can make an otherwise great solution a little more vulnerable to competitors in the marketplace.
Select Critical Chat Features: Best-of-Breed vs. MVP
Given the variety of potential use cases for in-app chat across different industries, chat’s intended function will determine which features are essential. A live chat module for customer service, for example, may need a way for the customer service associate to prioritize and queue incoming messages. A peer-to-peer direct messaging app may prioritize typing indicators and read receipts higher than a group chat designed for a high number of concurrent participants would.
Regardless of use case, one fact remains consistent: As dedicated chat and messaging apps like WhatsApp, Slack, Facebook Messenger, and iMessage have grown both more sophisticated and more popular, consumers today have become accustomed to a rich chat experience, taking convenient features like reactions and link previews for granted. This means that although the following core features may be enough to get a minimum-viable in-app chat function off the ground, this type of experience risks disappointing today’s users.
The more complex the features required, the greater the time and expense required for in-house development. The best API solutions, on the other hand, should offer a library of these features and allow you to choose the ones most important to your users.
Core In-App Chat Features for an MVP Offering
These bare-bones features will need to be developed to support any type of in-app chat or messaging app. Think of them as the project’s foundation, upon which further customization may be required. Keep in mind that the time and cost estimates included in this article were calculated for this type of MVP; additions from the list of advanced features below will require a larger investment. It can be surprisingly difficult just to get these basic functions to work together as expected with the seamless experience we take for granted as users of modern chat apps. After all, these apps were developed, tested, and improved by dedicated engineering teams over many years.
- Message drafting and editing window with keyboard
- Chat window with ability to separate messages by sender and organize messages chronologically
- Front-end/UI integration with consumer side of your app
- Back-end integration with admin side of your app
- Functional commands to send an outbound message, receive, interpret, and display an incoming message, and store messages in an ongoing conversation
Advanced Chat Features to Consider
Depending on your use case and your users’ expectations, some of the more advanced features below may actually be considered mission critical. Others can enhance the overall user experience, helping to drive engagement and retention while giving your brand a competitive polish.
- Support for emojis, gifs, in-line images and videos, and file attachments
- Threads and replies to keep the main conversation on topic
- User-friendly group chats and direct messages
- Multi-tenant and team functionality to separate unaffiliated groups of users from each other
- Link previews for secure and efficient sharing
- Ability to incorporate end-to-end encryption to keep messages secure and out of the hands of advertisers and bad actors
- Message search functionality to save users from endless scrolling when they need to find something
- Reactions like hearts, laughter, applause, etc.
- Capability to connect chatbots via webhooks to conserve human bandwidth in sales and support use cases
- Slash commands to help users automate common tasks
- Read receipts and typing indicators to keep users engaged between messages
- Admin moderation capabilities to prevent inappropriate or unsafe behavior
- View a complete list of advanced chat features
Real-World Example: Feature Depth & Reliability with TaskRabbit
TaskRabbit, the app that connects consumers with local contractors who help with everyday household tasks from cleaning and moving to handyman work, originally developed its chat solution in house. Chat is a critical TaskRabbit feature, allowing users to vet potential hires and discuss terms and details of the work they need done. After nearly 10 years of service, that in-house chat solution was struggling to keep up: Its performance was unreliable, and unacceptable lag time between a message sending and being received was causing miscommunications between users and taskers.
TaskRabbit also needed advanced new features like the ability to book appointments through forms directly available inside chat, which would reduce friction for users. The TaskRabbit team had to choose between rebuilding their chat feature internally or buying an API-based solution. Read the case study to find out what they chose and how the project turned out.
Identify Risks Involved with Building vs. Buying Chat
All technology and technological investments come with risk, but the amount and type of risk involved in building or buying in-app chat can vary greatly. Product managers need to assess what level of risk exposure is acceptable and what risks can be minimized or prevented as part of the development or integration process. Critical areas for review include security and compliance, data storage, and vendor lock-in, along with overall reliability, performance, scalability, and technical debt.
Security & Compliance
No company wants to be listed among the victims when the next big breach makes headlines or be held liable for customer data compromised in an attack. As attacks continue to grow more sophisticated, robust security measures must be built into any type of in-app chat from day one. This means including common-sense measures like encryption of data in transit, encryption of data at rest, proper user authentication and identity security measures like MFA/2FA, and enforcing the principle of least privilege for user permissions as well as infrastructure permissions on the back end.
Security best practices like these are universally required as part of regulatory compliance standards for each major industry: HIPAA for healthcare and related fields, FERPA for education, and PCI DSS for financial services, with standards like SOC 2 compliance, ISO 27001, and GDPR applying broadly across most tech-infused industries.
One risk of buying a chat solution is reliance on a third party to maintain stringent security baselines. Make sure any vendor you’re considering gives you the tools you need to meet or exceed compliance standards for your industry and provides timely, transparent communication about their security protocols. We recommend seeking out providers who treat security as a core business practice rather than an afterthought on a checklist.
Though it can require a leap of faith to trust a third-party vendor, it can also be costly and labor intensive to build and maintain adequate security in house. When you consider that all of a chat provider’s security resources are dedicated to chat security instead of being spread out to defend a broader product surface area, it’s possible that their SecOps team would stay more vigilant in the long term than an internal team tasked with chat as a one-off project. And as you consider the overall cost of developing in-app chat from the ground up, remember that it’s remarkably easy to make a security mistake or leave a loophole exposed in a V1 product.
Long-Term Scalability
So far, in-house chat development might seem like a preferable option for companies with enough engineering resources and time to spare. But another common mistake in the initial planning and scoping phase can hinder long-term success: Failure to adequately anticipate growth and architect for scalability. It’s wise to build chat infrastructure that can handle far more channels, active users, and concurrent sessions than you might initially expect. Fast growth in users and concurrent connections — normally a good thing — could force a massive rebuild of core components.
Scalable chat infrastructure can be tricky to nail even for experienced engineering and DevOps teams. One reason is that most cloud Infrastructure-as-a-Service (IaaS) pricing models simply don’t make sense for the chat use case. Take this tutorial using WebSockets on Cloud Run for example: The author builds chat on auto-scaling infrastructure that can support up to 250,000 concurrent connections, which sounds great. But the compute fees quickly get out of hand, with the author’s own infrastructure cost estimate landing at $62,600/month. Building chat with Firebase yields similar results: this popular platform is optimized for developing and hosting other types of apps, but the high cost of scaling chat leads many teams to seek out Firebase alternatives.
A dedicated chat provider, on the other hand, spreads infrastructure and development costs across many client organizations and can afford to invest in the right scalable technology up front. Building chat from scratch with a language like C++, Go, or Scala, for example, may initially be more difficult and costly than building on Cloud Run or Firebase, but pays off as user counts grow. With the right chat API provider, you can rest assured that predictable infrastructure spend and load balancing are taken care of.
Reliability & Performance
One major risk of in-house development is that even a massive investment of time and money can result in a chat feature that is buggy, only works intermittently, or doesn’t work at all. Critical performance features like speed and response time require a great deal of testing and optimization, and a cumbersome experience can turn users away. Chat infrastructure also needs to be highly available with near-100% uptime, requiring 24/7 monitoring and a plan to fix any issues immediately. No solution will be perfect in this regard, but SaaS vendors do take responsibility for performance as part of their service agreements.
Data & Storage Ownership
Both physical data storage and that data’s legal ownership can present complex challenges. Some companies, especially those in industries like finance and healthcare that are particularly vulnerable to attacks, may be wary of trusting a third-party vendor with customers’ personal data and/or with their proprietary trade secrets. But it’s worth noting that best practices around data storage and security have evolved in recent years and that maintaining a private data center is not necessarily the most secure option.
Consider, for example, that most reputable vendors build their products and store their data on industry-standard cloud infrastructure from AWS, GCP, or Azure. These services are required to meet the most demanding security standards, with data encrypted in transit and at rest and stored in highly secure data centers with redundancy across multiple geographic regions. They also include strong access control and identity security features like role-based access management. And if your in-house dev team would use the same cloud infrastructure anyway, the risk level is essentially the same.
In most situations, rights to data ownership and usage end up being more consequential than storage security. When considering buying a chat solution, make sure the vendor agrees not to mine and sell user data or otherwise collect it inappropriately. Some inexpensive and freemium options have been known to do this.
Decision Ownership
Internal development will likely give you the most ownership over architectural decisions, new feature priorities, and custom integrations. The downside to this is that each decision takes time to research and approve, and may be influenced by incomplete or unproven data. A vendor’s API or SDK solution will likely have been tested and proven across a wide variety of use cases, so you can trust that major functional decisions have been carefully made and focus instead on creating the best experience for your users.
Technical Debt
As discussed above, buying a ready-made chat solution can result in less ownership over bug fixes and new feature priorities than with internal development. If you request a feature whose benefits are highly unique to a niche industry, for example, a vendor won’t have a strong incentive to prioritize that feature over common requests from multiple customers. On the other hand, if you choose internal development, you risk tolerating a higher amount of technical debt in the interest of staying on schedule and on budget.
Technical debt accumulates when project leaders choose to temporarily accept an imperfect or incomplete solution in the interest of focusing on more pressing priorities. These known issues will require additional attention later and may degrade the user experience during your product’s earliest and most consequential launch phases. In the worst cases, poor architecture can make technical debt nearly impossible to resolve in the future.
Cross-Platform Development
Chat will likely need to function similarly across iOS, Android, web, and possibly desktop native platforms. Each platform presents its own unique challenges and requires a different developer skill set. Organizations that choose to build chat will need to invest equally in development across each of these platforms or risk delivering a disappointing and inconsistent experience on one or two of them, inviting a storm of negative user reviews.
Vendor Lock-In
Conventional wisdom tells us to be wary of forced long-term vendor commitments, both technical and financial. An expensive multi-year contract can be difficult to cancel if the solution proves unsatisfactory or if priorities shift. Worse, a vendor’s decision to discontinue or drastically alter their product can force a rushed and technically challenging migration to a new product. At that point, you may wish you had chosen to build your own solution in the first place.
The risk of vendor lock-in is real, but many product managers fail to anticipate the similar or even worse problems that can occur when they’re locked into a flawed solution that was developed internally. If an in-house build becomes unwieldy or outdated or if key developers leave — perhaps the only developers who really understand how the product works — it can be even more difficult to migrate off your own in-house solution than from vendor to vendor. SaaS companies, at least, tend to build automated migration tools into their offerings.
The takeaway on vendor lock-in, then, is that no solution should be treated as entirely permanent. If you choose to build chat in house, make sure your code is well documented and the overall architecture will make sense to any skilled engineer outside of the original dev team. If you choose to buy an in-app chat solution, make sure you trust the vendor’s financial footing and market stability and confirm its product is modular enough that migrating away from it in the future would not cause a catastrophic failure for your own product.
Make the Final Build vs. Buy Decision
The decision to build or buy chat functionality can’t be made lightly. It plays a direct role in your product’s ability to delight users and solve their problems, driving engagement and retention. The decision also has significant financial implications, with an impact on budgeting and prioritization of engineering resources. It’s a decision that must be made with your organization’s unique value proposition, customer base, goals, and requirements in mind. Paired with these factors, the analysis above should help to produce an exhaustive list of pros and cons of building or buying in-app chat functionality, supporting a carefully informed decision.
For many organizations, the advantages gained in up-front cost, total cost, time to market, and feature depth will make a chat API or SDK solution the logical choice. Still, for others with enough cash and development resources available or with a completely revolutionary vision for how chat looks and functions, in-house development may be worth the investment. If you and your team are still compiling your evaluation and could use some input from a technical expert in chat development, please don’t hesitate to contact us.
