Build vs. Buy In-App Chat: The Ultimate Decision Guide

Adding in-app chat is one of the most common (and underestimated) product decisions teams face.

Today, AI has made it easier than ever to prototype messaging features quickly. A small team can scaffold a working chat experience in days, not months.

But shipping a demo is not the same as running a production chat system.

The real decision comes down to whether you want to own, operate, and scale chat long-term, or rely on an API built specifically for that purpose.

In this guide, we'll compare:

• Building chat in-house (with and without AI)

• Building on top of a chat API or SDK

We'll focus on production reality, not just time-to-first-version, so you can make a decision that holds up six months, one year, and five years after launch.

The New AI Reality

AI has fundamentally changed how teams approach building chat.

Tasks that once required weeks of setup (think data models, WebSocket handling, and basic message flows) can now be scaffolded in hours. With modern frameworks and LLMs, a small team can generate a functional chat prototype remarkably quickly.

This has shifted the build vs. buy conversation, but it hasn't eliminated it.

AI Lowers Time-to-First-Version

AI excels at accelerating early development. It helps teams:

• Generate boilerplate and reference implementations

• Explore architectures and edge cases faster

• Ship internal demos or MVPs with minimal upfront investment

For proving an idea or validating user demand, this is a major advantage. Building chat is no longer the bottleneck it once was, at least at the prototype stage.

AI Does Not Remove Operational Ownership

What AI doesn't do is run your system once it's live.

After launch, you still own:

• Uptime, latency, and delivery guarantees

• Scaling behavior under real-world load

• Message ordering, consistency, and data integrity

• Abuse patterns, spam, and adversarial behavior

• Incident response, monitoring, and on-call rotation

AI can suggest fixes. It doesn't carry the pager.

Running chat in production means operating a real-time, stateful system where failures are immediately visible to users.

The Real Cost Starts After v1

The hardest part of chat is everything that comes after the first version.

As usage grows, teams are forced to:

• Harden early architectural decisions

• Rework systems that don't scale cleanly

• Add moderation, compliance, and reliability layers

• Support new platforms, regions, and user expectations

This is where many AI-built chat systems stall or become expensive to maintain. The initial speed gains fade, and long-term ownership costs take over.

The build vs. buy decision, then, isn't about whether AI lets you build chat faster. It's about whether you want to own a production messaging system for the lifetime of your product (or offload that responsibility to an API designed to handle it).

Step 1: Evaluate Your App

Before making the decision to build or buy in-app chat, you'll want to zoom out and start with a foundational question:

How closely tied is chat to the core value your product delivers?

In other words, is chat the experience you're selling, or is it a feature that enhances something else? Understanding this distinction will help you determine whether the investment required to build chat from scratch is truly warranted, or whether a modular API/SDK approach would be more aligned with your goals.

Here are key questions to help you assess where chat fits in your product strategy:

1. Is chat a core differentiator or a supporting feature?

• Chat is a differentiator if it is the experience. For example, you're building a new messaging platform, real-time collaboration tool, or social product.
• Chat is a supporting feature if it enhances your product's core workflows, like connecting customers with support, enabling sellers and buyers to interact, or facilitating team coordination.

If chat is not what sets your product apart in the market, it likely shouldn't require the same level of internal investment as your primary differentiators.

2. Will chat solve internal or external problems?

• If the goal is to improve internal workflows (such as agent communication, operations efficiency), chat is non-billable and unlikely to drive direct revenue.
• If chat directly supports user-facing experiences (such as boosting retention, driving conversions, enabling core interactions), it's more strategic, but still must be balanced against other roadmap priorities.

Features that don't generate revenue directly, yet consume major engineering time, can slow growth and innovation elsewhere.

3. Would you build other infrastructure tools from scratch?

• Few teams today would attempt to build their own email platforms, HR systems, office productivity suites, or project management tools. Even in data infrastructure, where customization used to be the norm, teams have embraced platforms like Snowflake, dbt, and Fivetran to standardize workflows and move faster.

Chat is following this same path. With high-quality, flexible chat platforms already available, investing heavily in building from the ground up often means re-solving a problem already solved.

Step 2: Weigh the Opportunity Cost

AI has reduced the time it takes to build a first version of chat. It hasn't reduced the opportunity cost of owning it.

Engineering resources are still finite and most valuable when applied to your product's core differentiators, not to operating supporting infrastructure. When developers build chat in-house, the real cost is what those engineers won't be working on once chat is live.

That lost time often comes at the expense of features that would have improved your product's competitiveness, enhanced user experience, or driven direct revenue. In most cases, those tradeoffs aren't worth it.

"It's kind of tempting, right? If you Google it, you'll find articles like 'Build Your Own Chat In One Week.' But then, you realize these additional use cases like muting users, creating channels, kicking people out of channels, and a million other things—that's when complexity creeps in." — Diego Lopez, CTO at Paired. Read the case study.

The stronger and more specialized your engineers are, the higher this tradeoff becomes. Diverting them from high-impact product work to maintain real-time messaging infrastructure slows innovation elsewhere.

Even when customization is required, a flexible chat API or SDK can provide control without full ownership. That allows teams to focus on tailoring the experience, while avoiding the ongoing maintenance, monitoring, and scaling costs that persist long after launch.

Step 3: Estimate Financial Investment

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.

While in-house development often seems like a bigger up-front investment with lower long-term costs, that breakeven point can be misleading. The idea is that recurring SaaS fees eventually surpass the one-time build cost, but in reality, ongoing maintenance and scaling often push that break-even much farther out than expected.

Theoretical Build vs. Buy Cost Over Time

On paper, build vs. buy cost models often suggest that in-house development becomes cheaper over time. For teams with deep pockets and a long planning horizon, that assumption can still appear reasonable.

In practice, it rarely holds up—especially in the AI era.

AI lowers early development costs, but it also makes cost curves less predictable. Teams reach production faster, but they often do so with architectures that haven't been tested under real-world load. As usage grows, hidden costs emerge in the form of scaling issues, performance bottlenecks, and rework.

For most organizations, the up-front investment to build chat (combined with ongoing infrastructure, maintenance, and operational risk) far exceeds the perceived savings of avoiding usage-based pricing. In many cases, the cost lines never meaningfully converge.

To control spend, teams that build in-house often freeze feature development after launch and focus only on keeping systems running.

That's why theoretical cost models aren't enough. A realistic build vs. buy decision requires accounting for long-term ownership, operational risk, and the true cost of running chat in production.

Cost to Develop Chat Functionality In-House

The cost to build chat in-house depends on factors like AI tools, developer salaries, team experience, and the complexity of your use case.

Below, we'll estimate in-house build costs using two scenarios: a low-end estimate for a basic chat feature built as quickly as possible (with AI assistance), and a high-end estimate for a more complex offering that accounts for common challenges.

Both scenarios assume experienced engineers, minimal competing priorities, and no major setbacks—best-case conditions, even with AI in the mix.

Calculating Initial Chat Development Cost

Building a custom in-app chat solution typically requires 1--6 months of development, depending on your AI usage. Costs can vary widely depending on scope, team size, and location.

→ Low-End Estimate: AI-Assisted Basic Chat

• Team: 2 skilled developers
• Location: Lower-cost market ($100k/year salary)
• Timeline: 1 month
• Labor Cost: ~$16,666

Infrastructure Costs (estimated):

• AWS services (EC2/Elastic Beanstalk, S3, RDS): ~$1,500/month
• AI tooling (LLM usage, developer tooling, experimentation): ~$500/month
• Total Infrastructure (1 month): ~$2,000

Total Low-End Build Estimate: $18,666 over 1 month
(Does not include unplanned delays, QA, or iterative changes.)

→ High-End Estimate: Full Collaboration Tool (Slack-style MVP)

Note: AI can reduce development time even in high-end builds by accelerating implementation and iteration. In practice, however, these gains are often offset by additional testing, rework, and operational hardening required to support real-world usage. As a result, total time to a production-ready launch typically remains in the 4 - 5 month range.

• Team: 6 developers
• Location: San Francisco Bay Area (~$200K/year salary)
• Platforms: iOS, Android, Web
• Timeline: 5 months
• Labor Cost: ~$500,000

Infrastructure Costs (estimated):

• Cloud infrastructure (higher concurrency and storage needs): ~$4,000/month
• AI tooling (LLM usage, moderation pipelines, experimentation): ~$1,000/month
• Total Infrastructure (5 months): ~$25,000

Total High-End Build Estimate: $525,000 over 5 months
(Conservative estimate, assuming MVP-ready launch.)

These two scenarios show the wide range of upfront investment required. And both still exclude long-term costs like maintenance, scaling, or iterative improvements post-launch.

Calculating Maintenance & 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.

→ Low-End Maintenance Estimate:

Let's assume things go smoothly:

• The original two-person dev team built a horizontally scalable solution on AWS Elastic Beanstalk.
• Ongoing maintenance requires two developers for two months/year to handle minor fixes: ~$33,332
• Infrastructure usage increases with scale, averaging ~$10,000/month annually. Infrastructure cost for 12 months: ~$120,000

Total year-one maintenance cost: ~$153,332
Running total after 14 months: ~$189,665

→ High-End Maintenance Estimate:

For a more complex, feature-rich chat tool:

• Two senior engineers contribute two months each throughout the year: ~$66,667
• Strong user adoption drives infrastructure cost to ~$20,000/month. Infrastructure cost for 12 months: ~$240,000

Total year-one maintenance cost: ~$306,667
Running total after 17 months: ~$826,667

After the first year in either scenario, IaaS costs will, of course, recur perpetually, and some degree of maintenance will still be required. 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. Even with AI accelerating parts of development, it can still take five to ten years or more before the cumulative cost of building in-house approaches the total cost of buying a managed chat solution over the same period.

Cost to Buy an In-App Chat Solution

Just like building chat in-house, buying an API-based or ready-made chat solution comes with hidden costs. To evaluate this option accurately, it's important to consider more than just the subscription fee.

One common misconception is that SaaS or API-based solutions have no up-front cost. While implementation is still far less expensive than building from scratch, it's not free. At a minimum, you'll need:

• UI customization to match your product's branding
• Integration with your app and supporting systems (CRM, analytics, support tools)

Even plug-and-play tools like Tidio, designed for lightweight sales or support chat, still require setup and ongoing tweaks to remain effective.

Compared to plug-and-play options, chat APIs or SDKs offer greater flexibility, but they also require more developer time during implementation. That includes:

• Building the bridge between your app and the chat API
• Customizing the experience to meet UX and product needs

However, this cost is still significantly lower than a full in-house build. And for teams looking to move fast, many vendors (like Stream) offer UI kits that speed up deployment. Some customers have launched chat features in a live app in under a week using out-of-the-box components.

When evaluating any third-party solution, you should also consider:

• Usage-based pricing: High MAUs can trigger overages if not planned for
• Add-on features: "Optional" capabilities can become necessary, increasing costs
• Ongoing internal labor: Even with vendor-managed infrastructure, your team still needs to monitor and maintain the integration as business needs evolve

Here's a simplified formula to help estimate the total cost of ownership (TCO):

For reference: At 1 million monthly active users, leading chat-as-a-service solutions charge about $15,000/month. That's $720,000 over four years—still less than the nearly ~$900,000 up-front cost of a high-end in-house build.

In-App Chat as a Capital Expenditure vs. an Operational Expenditure

The rise of cloud infrastructure, and now AI-powered development, has reshaped how companies build and budget for software.

What once required large, up-front capital expenditures (CapEx) can now be handled as operational expenditures (OpEx)—lower-risk, recurring costs that are easier to manage. This shift applies directly to in-app chat.

When a choice is available, finance teams tend to prefer OpEx because:

• It's easier to forecast and budget.
• It avoids the risk of overspending on unexpected issues.
• It provides monthly or annual consistency in billing.

With a SaaS solution, the vendor absorbs much of the technical risk. If something breaks or needs scaling, you're not facing surprise development costs. You pay for reliability, often backed by monetary SLAs.

Because enterprise-grade SaaS solutions serve many clients, they:

• Distribute development and maintenance costs more efficiently.
• Bundle services into single line items that are easier to report.
• Offer pricing models that scale with usage and revenue.

This means you get enterprise-grade reliability and support without the overhead of building and maintaining the system yourself.

Capital expenditures, by contrast, are riskier in an AI-driven development environment. Faster builds can lead to earlier launches, but also to architectural decisions that are costly to revisit once systems are in production. When something breaks or needs to be reworked, the resulting spend is unplanned and difficult to contain.

For many teams evaluating the build vs. buy decision, the ability to treat chat as a scalable, predictable OpEx is a significant point in favor of third-party solutions.

Step 4: Evaluate Speed and Value

In today's environment, new technical investments are still under pressure to deliver fast, measurable returns. That pressure hasn't changed, but what counts as "fast" has.

AI has dramatically reduced the time it takes to prototype features like chat. A small team can now produce a working demo in days. But prototypes don't deliver ROI on their own. Value only appears once a feature is reliable, scalable, and trusted by users.

That's where speed still matters.

Pre-built chat APIs and SDKs optimize for time to production value, not just time to first version. They allow teams to ship features that are stable, observable, and ready for real usage, without months of infrastructure work.

Even with AI assistance, building a production-ready chat system typically takes several months once testing, cross-platform support, moderation, and operational readiness are factored in. That gap often delays meaningful ROI far longer than teams expect.

"Adding video and audio from scratch is extremely hard in my experience. I knew we needed something that would just plug in and work." — James Mtendamema, Founder at Campus Buddy. Read the case study. 

Competitive Advantage & Time to Market

Similarly, what "time to market" means has changed.

With AI, competitors are both shipping faster and more often. In this environment, spending months building and stabilizing a foundational system like chat can put teams behind before version one ever reaches users.

Using a chat API or SDK allows teams to move directly to feature-level differentiation. Instead of investing early cycles in infrastructure, teams can ship a production-ready chat experience and continue iterating while competitors are still hardening their first release.

Speed also matters for user metrics. In crowded app categories, engagement and retention can shift quickly. As chat becomes an expected baseline feature, delays (even short ones) can impact adoption and leave room for competitors to set user expectations first.

Step 5: Select Critical Chat Features

Chat needs vary by use case. A customer support chat may prioritize queuing and ticketing, while a peer-to-peer messaging app might emphasize typing indicators and read receipts. Group chats, meanwhile, often focus on scale and performance.

What's consistent across all use cases is user expectation. Apps like WhatsApp, Slack, Facebook Messenger, and iMessage have set a high bar with features like reactions, link previews, and media support now expected.

And now, the bar has been raised again by AI.

Today's teams expect:

• AI-powered onboarding bots (e.g., GPT-based assistants)
• Toxicity and content moderation using LLMs
• Real-time summarization and contextual insights
• Seamless integration with AI providers like OpenAI, Anthropic, and Hive

Building these features in-house is no small task. It requires custom pipelines, prompt tuning, moderation dashboards, and handling rate limits, latency, and edge cases. By contrast, Stream offers built-in support for popular AI providers, enabling teams to deploy advanced capabilities without starting from scratch.

While a basic MVP can launch with just core features, anything less than a modern experience may disappoint users. The more advanced the feature set, the more time and cost are required to build from scratch, whereas top API solutions provide these features out of the box, letting teams focus on what matters most.

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.

Even basic functionality can be challenging to implement smoothly. Modern chat apps feel seamless because dedicated teams have refined them over years of development.

• 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 Examples

Many companies have faced the same build vs. buy decision and opted to accelerate growth, reduce complexity, and scale faster by using a ready-made chat solution.

Here's how they made it work:

Rigi: Rapid Integration and 50% YoY Growth

Rigi, a platform that helps creators monetize content, needed a reliable chat experience to support growing communities.

• Solution: A single developer integrated Stream's React Native SDK in just a few hours.
• Result: Enabled fast time to market and contributed to 50% year-over-year growth.
• Impact: Improved community engagement and monetization for creators.

Nextdoor: Cutting Costs While Upgrading Chat

Nextdoor wanted to improve messaging between neighbors and reduce the cost of maintaining its existing in-house chat system.

• Switch: Replaced internal solution with Stream Chat.
• Savings: Reduced messaging-related costs by 50%.
• Value: Delivered richer messaging features while streamlining development.

Hudl: Powering In-App Community for Sports Tech

Hudl aimed to strengthen team communication and build more engaging in-app communities.

• Goal: Create a social layer without building from scratch.
• Approach: Integrated Stream Chat to enable real-time messaging.
• Benefit: Seamless setup and more time to focus on core product innovation.

Step 6: Identify Risks Involved

All technology and technological investments come with risk. But in the AI era, faster development increases the surface area for security, reliability, and long-term ownership decisions.

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
• Vendor lock-in
• Technical debt
• Overall reliability, performance, and scalability

Security & Compliance

Security must be built into your chat infrastructure from day one.

That includes:

• Encryption at rest and in transit
• MFA/2FA and strong authentication
• Least-privilege access for users and infrastructure
• Compliance with industry standards like HIPAA, FERPA, PCI DSS, SOC 2 compliance, ISO 27001, and GDPR

Vendor risk: You'll need to trust your provider to maintain these standards. Choose one that treats security as a core practice, not a checkbox.

In-house risk: Securing a custom solution is complex and time-consuming. A vendor focused solely on chat may be better equipped to keep up with evolving threats. AI-powered features introduce additional security considerations, including prompt abuse, automated spam, and data leakage through logging or model interactions.

Long-Term Scalability

Underestimating growth is a common mistake. If your system can't handle:

• A spike in users
• High volumes of messages or channels
• Complex concurrency loads

...you may be forced into an expensive, urgent rebuild. And some platforms scale poorly for chat and get costly fast.

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.

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.

"Knowing that Stream supports Enterprises, we are confident that your solution will help us to scale. Stream's global edge network, reliable infrastructure, and SLA uptimes guarantee efficient scalability. As the business expands into larger markets, we are confident that Stream Chat will scale alongside our user base." — Amar Amarsanaa, CEO and Co-Founder at Zaya. Read the case study. 

Reliability & Performance

In-house solutions risk:

• Laggy performance
• Buggy behavior
• Uptime issues without 24/7 monitoring

Reliable chat requires continuous testing, optimization, and a response plan. Vendors typically offer SLAs and actively manage uptime, making performance a shared responsibility.

Data & Storage Ownership

Both physical data storage and that data's legal ownership can present complex challenges.

Most leading chat providers, including Stream, rely on trusted cloud platforms like AWS, GCP, or Azure, offering:

• Encryption at rest and in transit
• Role-based access controls
• Compliance with standards like HIPAA, GDPR, and SOC 2

But today, especially with the rise of AI, storage alone isn't enough. How vendors use your data matters just as much.

Stream's privacy stance is clear. We do not mine, sell, or use customer data to train AI models. We're committed to protecting user privacy, especially for regulated industries. This sets Stream apart from some low-cost or freemium providers that may engage in AI-driven data harvesting or monetization.

If you're evaluating a third-party chat vendor, go beyond basic security. Ask: Who owns the data? Is it used for AI training? What privacy guarantees are in place?

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

Internal teams often cut corners to stay on schedule, leading to:

• Known issues that degrade UX
• Long-term architectural limitations
• Costly refactors down the road

AI can accelerate delivery, but it can also accelerate technical debt by making it easier to ship solutions that work initially but are difficult to evolve or debug over time.

Buying a chat solution shifts that maintenance burden to the vendor. While you won't own the product roadmap, the right partner will keep you informed and responsive to evolving needs.

Stream addresses this concern head-on by actively shipping improvements and fixes, publishing a transparent weekly changelog, and listening to customer feedback to inform feature priorities.

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 negative user reviews.

Vendor Lock-In

Vendor lock-in is a real concern, especially with multi-year contracts, shifting priorities, or platform changes outside your control. But what's often overlooked is that building in-house can lead to even tighter lock-in, especially if:

• The architecture doesn't scale or adapt
• Institutional knowledge is lost when developers leave
• Documentation isn't maintained for future teams

The good news is that not all vendors lock you in. At Stream, we design with portability and long-term flexibility in mind.

This means we support data export and provide tools to make migration easy. Our APIs and SDKs are structured to minimize coupling, making it possible to transition smoothly if needed. And we believe data belongs to you, not us.

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 long-term cost 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.