What is our primary use case?
I used Sendbird as part of testing and validating chat functionality in a mobile application. From a QA perspective, I found the platform to be stable and well-documented, which made it easier to verify messaging workflows and troubleshoot issues. The APIs were consistent and overall, it provided a reliable foundation for real-time communication features.
The flow I tested involved validating one-to-one chat between two users. I verified that messages were delivered and displayed correctly in real-time, checked message ordering and timestamps, and ensured unread message counts updated accurately. I also tested scenarios where a user went offline and came back online to confirm messages were synchronized properly. Additionally, I validated file attachments, push notifications, and basic error handling for network interruptions to ensure the chat experience remained reliable across different conditions.
My primary experience with Sendbird was from a QA perspective, focusing on validating the end-user messaging experience rather than implementing the SDK. I tested core chat workflows such as one-to-one messaging, message delivery and synchronization, unread counts, push notifications, file attachments, and behavior during network interruptions. I also verified cross-platform consistency, logged defects and worked with developers to validate fixes before release. Overall, my focus was ensuring the chat functionality was reliable, intuitive, and met the expected user experience.
What is most valuable?
From both a QA and product perspective, the Sendbird features I found most valuable are real-time messaging, read receipts, delivery receipts, typing indicators, offline synchronization, push notifications, file sharing, cross-platform SDKs and UI Kit, scalability, and of course, moderation and security.
From my perspective as a QA engineer, Sendbird helped our team deliver a reliable in-app messaging experience without having to build a chat solution from scratch. The platform's stability, documentation, and feature set made it easier to validate messaging workflows, identify issues, and ensure a consistent user experience across mobile platforms. This allowed the team to focus more on improving the product itself rather than solving underlying messaging infrastructure challenges.
From a QA perspective, using Sendbird likely saved significant development and testing effort compared to building a chat solution internally. Instead of spending time validating custom messaging infrastructure, our team could focus on testing the application's business workflows and user experience. Since the core chat functionality was stable, we encountered fewer issues related to message delivery or synchronization, allowing us to spend more time on edge cases, integrations, and release quality rather than debugging the underlying chat system.
What needs improvement?
One area that could be improved is the handling and visibility of unread message counts. In some scenarios, keeping unread counts perfectly synchronized across multiple devices, sessions, or after reconnecting can be challenging. More flexibility in configuring unread count behavior, along with clearer documentation and debugging tools for these scenarios, would make it easier for developers and QA teams to validate and troubleshoot messaging workflows.
Overall, my experience with Sendbird was positive. Beyond improving unread count synchronization, I think more built-in debugging and diagnostic tools would be valuable for developers and QA teams when troubleshooting real-time messaging issues. Additional test utilities or dashboards to inspect message delivery, synchronization status, and notification events would make it easier to reproduce and verify edge cases. While the documentation is generally good, adding more examples for complex scenarios such as multi-device synchronization, offline recovery, and notification behavior would further improve the developer and testing experience.
For how long have I used the solution?
I have been using Sendbird for two years.
What do I think about the stability of the solution?
Sendbird was a stable and reliable platform throughout my experience. During testing, the core messaging functionality such as real-time message delivery, synchronization, and notifications performed consistently. While we occasionally encountered edge cases, such as unread count synchronization or network reconnect scenarios, these were relatively minor compared to the overall stability of the platform. I kept raising issues with Sendbird's support team. Overall, I found Sendbird dependable for production use and well-suited for applications requiring real-time chat.
From my experience, Sendbird handled our application's messaging requirements reliably and scaled well for our use case. We did not experience issues with normal day-to-day messaging, and the platform consistently supported real-time communication across users and devices. While I was not responsible for load testing or infrastructure, I found the chat functionality stable and responsive during feature testing, regression testing, and release validation. Based on that experience, I believe Sendbird is well-suited for applications that need to scale as their user base grows.
How are customer service and support?
My experience with Sendbird's customer support was positive. The team was responsive and helpful in addressing technical questions, and together with the detailed documentation, it helped us resolve issues efficiently during development and testing.
Which solution did I use previously and why did I switch?
Sendbird was the primary chat solution used in the project I worked on, so I do not have direct experience migrating from another messaging platform.
What was our ROI?
I do not have access to organization-wide ROI metrics, so I cannot provide specific numbers. From my perspective as a QA engineer, using Sendbird likely saved development and testing time because the team did not have to build and maintain a custom chat infrastructure. It allowed us to focus on validating business workflows and user experience instead of troubleshooting core messaging functionality. This contributed to more efficient testing cycles and smoother releases, although I cannot quantify the exact time or cost savings.
Which other solutions did I evaluate?
To the best of my knowledge, the team considered solutions such as Firebase, Twilio Conversations, and CometChat before choosing Sendbird. I was not directly involved in the evaluation process, but Sendbird was selected for its comprehensive feature set, reliable real-time messaging, scalability, and ease of integration.
What other advice do I have?
I recommend clearly defining your messaging requirements before integrating Sendbird and taking advantage of its SDKs and documentation to speed up development. From a QA perspective, it is also worth planning test cases for edge scenarios such as network interruptions, offline synchronization, unread message counts, multi-device behavior, and push notifications. Overall, Sendbird is a solid choice if you are looking for a reliable, scalable chat solution without the overhead of building and maintaining your own messaging infrastructure.
I had a good experience with Sendbird. It provided a reliable and feature-rich messaging platform that simplified testing and helped our team deliver a quality chat experience without building the infrastructure from scratch. From a QA perspective, I appreciated its stability, documentation, and comprehensive feature set. While there are opportunities to improve areas such as unread count synchronization, debugging tools, and documentation for advanced scenarios, I would still recommend Sendbird to teams looking for a scalable and dependable in-app messaging solution. I rated this review an 8 out of 10.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)