💡 Target Audience: B2C Communities currently paying for fragmented plugins and expensive plans for Video, Live, Chat, and Translation features individually.

Modular pricing is not a discount — it is a deferred bill

Modular platforms are attractive at signup precisely because the first module is cheap. You buy chat. Six months later the roadmap says "add video". Then "add live". Then a Korean user asks why the app is English-only, and translation becomes a project rather than a setting.

Each addition is priced as a separate product, and — more expensively — integrated as a separate product:

The line that hurts is not any single subscription. It is the last three rows — the integration surface you now own forever. Every new product adds an identity mapping, a second set of retry semantics, and one more place to look when a message goes missing at 3 a.m.

What "in the pipeline" actually means for translation

Most platforms treat translation as a post-processing step: your client receives a message, calls a translation API, waits, then re-renders. Every device does this separately, so the same sentence is translated N times, latency is added *after* delivery, and the translated text usually is not stored — search and history stay monolingual.

HyperBabel treats translation as a property of the channel. A message carries its translations with it, so:

• the translation happens once per message, not once per recipient;
• history and search work in the reader's language, not just the writer's;
• a late-joining member sees translated backlog, not raw text;
• your client code does not orchestrate anything — it renders what it receives.

The same principle applies to live subtitles during a call or broadcast.

The published rate card

No quote requests, no "contact sales" for the numbers that decide your architecture:

Plans include a monthly quota that resets — Scale ($1,999) covers 10M messages, 30,000 HD + 10,000 FHD video user-minutes, 15,000 HD live-stream user-minutes, 20,000 minutes of speech translation, 5M translated characters and 500 GB of storage before any of the above applies. (Video and streaming minutes are *user*-minutes: a 10-minute call between two people uses 20.)

When Stream is genuinely the better choice

• You want polished UI components more than you want infrastructure. Stream's React/Flutter chat components are mature and save real front-end weeks.
• You need activity feeds, not just chat — ranked, aggregated social feeds are a distinct product Stream does well and HyperBabel does not offer.
• Your app is English-only and will stay that way. The translation advantage simply does not apply to you, so compare on chat features alone.
• You have already built deep customisations on their component library and the switching cost dominates.

Migration checklist

1. List the modules you pay for today, including any translation or transcription API billed separately.
2. Decide the UI question first. If you rely on prebuilt components, budget front-end time — HyperBabel gives you SDKs and reference demos, not a full drop-in component kit.
3. Start with one surface, usually 1:1 chat, and keep group/feed features on the old stack during the transition.
4. Collapse identity early. One identity model is most of the benefit; do it before you migrate history.
5. Move video after chat. Video sessions are stateless per call, so they cut over cleanly once auth is shared.
6. Turn translation on last — it is a flag, not a project, and it is easier to validate once traffic is already flowing.
7. Run one month in parallel and compare invoices, not estimates.

The 30-second version

Modular pricing sells you a cheap start and an expensive middle. Ask what your stack looks like *after* the next three roadmap items, not today — and count the integrations, not just the invoices.