An SDK for Chat

Is chat an important feature in SaaS tools?

People working together online need chat. It's the dominant mode of communication across laptops, phones, and tablets. Video has gained popularity massively since the global COVID pandemic, but it is still far exceeded by chat and commenting based communication. And even when video is used, chat is still a required feature. Chat is incredibly important in multi-user software.

For almost all SaaS applications, a human-to-human chat experience is crucial for the product to give its users all the value it can. Communicating with others right where you're working saves an incredible amount of time and context thrash. But it's not easy to build well.

Can you build a chat feature yourself?

You might not think of in-app chat as a problem which warrants an entire SDK. But really solving for chat and comments is far more complex than it looks at a glance. Many teams start building a chat feature and realize only weeks or months later that they wished they'd used a chat SDK or chat NPM package instead.

What are the minimum requirements for a chat feature?

To have even a basic chat feature, you need:
- Clear user identity
- Real-time messaging
- Notifications
- Deep linking

These four pillars make up the absolute bare minimum of a useful chat feature. If you remove even a single one, your users will not use the feature. Trust us -- we learned the hard way.

Why is user identity important in a chat application?

Plain and simple -- you need clear user identity for people to be able to understand who is who. Even more importantly, humans have evolved to recognise faces incredibly fast. Having profile photos is very helpful for spurring engagement and messaging. People are far more likely to message their teammate if they can see that person's face than if they just see their initials. Or worse, no indication that any other people might see their message.

What goes into adding messaging to an existing software application

Speaking of messaging, it's probably the most obvious part of a chat feature. But let me tell you... it's a surprisingly deep well. Chat that has only plain text is far, far less engaging than chat with formatting, link previews, and @-mentions. People have WhatsApp in their pocket with extremely rich chat. Your feature is implicitly judged against it.

Unless you have a couple years of engineering and design time, you won't implement every feature of an industry-defining chat app like WhatsApp or Signal. So, how close are you going to get? You can add plain text messaging in a day. Image attachments in a few days. Link previews in a few days. But we still haven't even scratched the surface of rich formatting, at-mentions, inviting people into the chat, or all the rest.

Are notifications important when building a chat feature in an existing application?

Last up in terms of a chat MVP, are the one-two punch of notifications and deep linking. Even if you built absolutely perfect user identity with profile photos and usernames and hover cards and you also perfected the ultimate message format with everything from image uploads to inline video -- none of it matters if you don't have effective notifications. How does a person know where an important conversation is happening? How do they find out if they've been mentioned? You need notifications to achieve this.

Right on the back of notifications is deep linking. For contextual chat to work, you need to be able to get back to right place when you click a notification. Depending on how your application has been built, this might be easy. Or it might be very hard. It all depends on your routing/URL structure as well as your user data model.

So, that's your starting point if you decide to build from scratch. Those for elements make up the most bare bones chat you can build that might work for your users (for a while).

Is there an NPM package that offers a complete chat implementation?

Yes, if you want an turn-key, high-end chat feature, you can start by building with a chat SDK. Using a mature toolkit like Cord, you can get the full chat feature set from day one with about 5% of the work.

What are the features of the Cord chat SDK?

• User Identity
  • User names
  • Profile photos
  • Online/offline status
  • Any other metadata your application needs
• Messages
  • Real-time websocket-based product experience
  • Rich text formatting
  • @-mentions
  • Reactions
  • Images
  • Video
  • Animated GIFs
  • Link-previews
  • Arbitrary metadata
• Conversation threads
  • Multi-person conversations with add/remove control
  • Privacy controls
  • Read/unread status for individual messages
  • Resolved/unresolved status (just like Google Docs!)
  • Arbitrary metadata
• Notifications
  • Deep links back to where the conversation happened
  • Seen/unseen status
  • Clicked/un-clicked status
  • In-app as well as email
  • Users have a strong preference for Slack integration
  • Users have strong preference for mobile integration
  • Arbitrary metadata
• Search
  • Full text search for messages
• and Client JavaScript APIs
  • Ability to send messages on behalf of users
  • Ability to send messages on behalf of non-users (system messages)
  • Ability to add and remove users from conversations
  • Ability to create message conversations with arbitrary sets of participants
  • Ability to fetch all messages in a conversation, per user, etc.
• Webhook Events
  • Key events like message sent, conversation created, etc.

That is a long list. We've boldly called it the "minimum required" feature set. This isn't the bare bones might-work MVP. This is the minimum feature set for a compelling feature that users actually use. We know because we kept iterating until we had a compelling chat. There's no magic in this list. Just hard-earned understanding of what works. It took us multiple years to get here.

Still, a good engineer should naturally be sceptical that so many things are required.

After all, you probably just need a "basic", "standard" chat in your app, right?

One of the things we often hear from teams who are considering building their first communication features is this: "Oh, we're just building a standard chat feature." Interestingly, we never hear this from experienced teams. In fact, many teams go searching for a chat SDK after they've already spent multiple developer months trying to get to "basic" and "standard" chat on their own.

The difference between the senior teams and the less experienced ones is less about technical ability and more about perspective. It's actually because seasoned teams understand some things that aren't obvious before you venture into the wilderness of building your own chat. Specifically:
- Pre-existing user expectations
- Conflicting user priorities
- All the work that happens *once you have* a successful MVP

What does it take to go from a chat MVP to a fully-baked chat experience?

The first big hurdle is existing user expectations.

Most end users perceive chat to include these features:

• Message input and sending
• Multi-party conversations (like slack channels)
• Private conversations (between themselves and whichever other people they need to communicate with)
• Some way to find all their messages and conversations

Users don't know that they expect these features. They won't tell you that they won't use a chat features that doesn't have them. They just won't use the feature.

You will only learn that these are their expectations if you engage in extensive user experience research or you build your first few generations of chat... and watch them fail in production.

Users only know what they see when they pull their phone out of their pocket. When they open their email. What they see in Slack or Microsoft Teams. In those contexts, literally everyone of the features described above are present.

A key takeaway for anyone building their own chat is that your biggest competition is the existing platforms people already use. And more than that -- the existing social groups they interact with.

You have to think of an MVP in these terms. A technical MVP is not the same thing as "worthwhile replacement to my existing thing that I already know how to use".

When you realize that this is the bar you must reach, it becomes a lot clearer that starting from scratch isn't an efficient way to get there.