This post is for our Paid Subscribers. If you haven’t subscribed yet,
.
.
.
Clarifying Questions
Before diving in, I would want to align on scope before committing to a direction, because the phrase “web service that enables other developers to create online chat applications” actually spans two meaningfully different product categories.
API/SDK infrastructure platform vs. white-label template product: Is the goal to build a backend-as-a-service chat infrastructure (think Twilio’s Conversations API, Sendbird, or PubNub) that developers integrate into their own apps, or a fully-built, customizable chat application that developers deploy as-is? One is developer infrastructure, the other is closer to a template product. The engineering architecture, pricing model, and go-to-market motion are fundamentally different between the two.
Target developer segment: Are we primarily targeting large enterprise engineering teams adding chat to an existing scaled product, or smaller startups and indie developers who want to add chat without building the underlying infrastructure from scratch? These segments have different documentation needs, different procurement cycles, and different willingness to pay.
Scale expectations at launch: Real-time chat infrastructure has fundamentally different engineering requirements at thousands of concurrent WebSocket connections versus tens of millions. Knowing the expected scale shapes core architecture decisions from day one, particularly around message delivery guarantees and connection management.
Monetization model: Is the business model usage-based pricing tied to monthly active users and message volume (common in this category), seat-based subscription, or a freemium-to-enterprise funnel? This shapes how we design the free tier and what guardrails we instrument.
Regulatory and geographic scope: Are we building for a global audience from day one, with GDPR, data residency, and right-to-left language rendering in scope immediately, or focusing on a specific geography first? This is a meaningful scope decision since retrofitting proper internationalization into an already-built platform is significantly more expensive than designing for it upfront.
For this answer I will assume we are building a developer-facing chat infrastructure platform, a Twilio Conversations or Sendbird-style API and SDK, serving companies of varying sizes who want to add real-time messaging into their own product without building and maintaining that infrastructure themselves. The business model is usage-based pricing tied to monthly active users and message volume, with a generous free tier designed to drive self-serve adoption before an enterprise sales motion. We are building for a global audience from the start.
Product Description
The product is a set of RESTful APIs, real-time WebSocket APIs, client SDKs across major platforms (iOS, Android, React, Vue, and plain JavaScript), and optionally pre-built UI components that let a developer add real-time one-on-one and group messaging, typing indicators, read receipts, persistent message history, file and media sharing, and presence detection into their own application in days rather than months. The underlying infrastructure handles reliable message delivery under network interruption, message ordering guarantees, and scaling persistent connections to millions of concurrent users, problems that are genuinely hard distributed-systems challenges that most product teams building chat as a secondary feature would rather not own and maintain themselves.
This sits squarely in the developer infrastructure and platform-as-a-service category, a market that research firm MarketsandMarkets valued at approximately $9.2 billion in 2023 and projects to grow to around $22 billion by 2028, a compound annual growth rate of roughly 19 percent. The leading incumbents include Sendbird (founded 2013, raised over $220 million, serves companies like DoorDash, Carousell, and Hinge), Twilio’s Conversations product (part of a company with over $3.5 billion in 2023 annual revenue), PubNub (founded 2010), and Stream (founded 2015, raised over $38 million). Pricing in this category typically follows a tiered monthly active user model: Sendbird, for example, charges roughly $399 per month for up to 5,000 MAUs at its Growth tier, scaling significantly from there. The core competitive tension is that the incumbents offer breadth and brand credibility, but developer community reviews consistently surface complaints about documentation quality, pricing unpredictability at scale, and customization limitations around UI components, creating real openings for a well-executed challenger.
The fundamental value proposition is straightforward: building reliable real-time chat from scratch requires solving WebSocket connection management, message fan-out architecture, delivery guarantees under intermittent connectivity, presence and typing-indicator state synchronization, and scalable message storage and indexing. For a team whose core product is a marketplace, a healthcare app, or a gaming platform, those are not problems worth solving from scratch. Buying solved infrastructure at a predictable cost is almost always the economically rational choice, which is why this category has attracted substantial venture investment and sustained enterprise spending.
Define Goal
The core problem is that real-time chat is a highly recurring need across hundreds of product categories (marketplaces, healthcare platforms, gig economy apps, gaming, professional tools) but building it reliably from scratch is expensive and technically complex, creating sustained demand for infrastructure that abstracts that complexity away behind a clean API and SDK.
The goal I want to focus on is becoming the default choice for “add chat to my app” among growth-stage and enterprise product teams, measured by developer adoption velocity and retention, competing on reliability, integration speed, and pricing predictability against Sendbird, Twilio Conversations, and PubNub.
The north star metric I would propose is monthly active integrations with at least 100 MAUs sending messages in a 30-day window. This measures integrations that have moved beyond toy prototype stage into real, live product usage, which is the leading indicator of sustained revenue and of word-of-mouth within developer communities. I prefer this over raw signup count (too shallow, too easily gamed) and over total message volume (distorted by a small number of very high-volume customers). An integration that has 100 real users actively messaging is an integration that is in production, generating organic developer advocacy, and likely to convert to paid usage as it scales.
User Segmentation
Developer Customers
Startup and small-team developers (primary focus): Typically 1 to 10 person engineering teams, 25 to 40 years old, building a new product from scratch with limited bandwidth to spend on infrastructure that isn’t their core differentiation. They want the fastest possible time-to-integration, clear example-rich documentation, and a generous free tier. They are price-sensitive early but become high-value customers if their product grows. Churn risk is high if integration friction is too high at the evaluation stage.
Enterprise engineering teams: Teams at companies with 500 or more employees adding chat to an existing large-scale product. They need documented SLAs (typically 99.99 percent uptime commitments), SOC 2 Type II compliance, data residency options, and volume pricing. They have 60 to 180 day procurement cycles and require security reviews. They are low-churn once onboarded but expensive to acquire.
Agencies and consultancies: Technical teams building chat features on behalf of multiple client projects. They value multi-tenant account management, the ability to replicate a proven integration pattern across unrelated client codebases, and white-label presentation to their clients. A single agency adopting our platform as their default chat stack can drive 5 to 15 client integrations per year, making them a highly capital-efficient acquisition channel.
Platform and marketplace companies: Two-sided marketplace operators (gig platforms, rental marketplaces, freelance networks) needing moderated, often anonymized buyer-seller or worker-client messaging. They have specific recurring requirements around message proxying, contact-info scrubbing, and dispute-resolution access to message history. This is a distinct enough use case to warrant purpose-built features.
Mobile-first app developers: Teams building primarily for iOS and Android with particular requirements around offline message queuing, push notification integration, and battery-efficient real-time connections that differ meaningfully from web-first developers.
I will focus this answer primarily on startup and small-team developers, because they represent the highest volume of potential integrations, drive the organic word-of-mouth growth that is the most cost-effective acquisition channel in the developer infrastructure category, and are the segment most directly affected by the integration friction and pricing-predictability pain points that represent the biggest competitive openings against incumbents.
Pain Points
Synthesising developer community discussions (Hacker News threads, Reddit’s r/webdev and r/programming, G2 and Capterra reviews of existing chat providers), plus documented patterns from how similar developer infrastructure categories (payments, SMS, authentication) evolved, these are the most significant pain points.
