💡 Target Audience: Engineering teams wasting months building standard chat/video features on top of raw websocket pipes.

A pipe is not a chat product

Pusher and PubNub are genuinely good at what they do: move JSON between clients, reliably, at scale. The mistake is assuming that "real-time delivery solved" means "chat solved". It solves roughly the first 15% of the problem.

Here is the honest inventory of what you still own after you have a working socket:

None of these rows is hard in isolation. That is exactly the trap: every one of them is a two-week task and a permanent maintenance obligation. The unread-count service that was "done" in March is the thing paging you in October when a user has 2.1 billion unread messages because of an off-by-one on a reconnect.

The build cost nobody puts in the spreadsheet

When teams compare a raw pipe's subscription against a chat platform's subscription, they compare the wrong two numbers. The real comparison is:

raw pipe TCO  = subscription
              + (build weeks × loaded engineer cost)
              + (maintenance weeks/year × loaded engineer cost, forever)
              + separate video vendor
              + separate translation vendor
              + object storage + egress
              + the on-call cost of owning delivery semantics

The subscription is usually the smallest term in that expression. The last line has no invoice at all, which is why it never makes the slide — and why it is the one that wakes people up.

What HyperBabel gives you instead

One API key, one identity, one event stream. Chat channels, history, presence, typing, receipts, blocking, moderation hooks, file delivery, push fan-out, video, live streaming and translation are the same product with the same auth. There is no glue layer because there is no seam to glue.

Metered simply: peak concurrent connections by plan, plus messages, connection minutes, active channels, translation characters, video minutes and storage — all at published rates, with $0 egress.

When a raw pipe is genuinely the better choice

Be honest about your workload. Pusher or PubNub is the right tool when:

• Your real-time payloads are not conversations. Live dashboards, sports scores, collaborative cursors, IoT telemetry, order-book updates — none of these need history, receipts, or moderation.
• You need a custom protocol. If your message shape is nothing like chat, a general-purpose platform's opinions become friction rather than leverage.
• You already built the chat layer and it works. Rewriting a working, paid-for system to save subscription dollars is rarely the best use of a quarter.
• You need one specific primitive — presence, or a trigger channel — and nothing else.

Use a pipe for transport problems. Use a platform for product problems.

Migration checklist

1. Inventory what you built. List every service in the table above that you currently own. That list *is* your business case.
2. Start with the pieces you dislike maintaining — usually unread counts, reconnect replay, or push fan-out.
3. Run both transports in parallel. New channels on HyperBabel, existing channels on the pipe.
4. Move history reads before history writes, so the old store becomes read-only before it becomes redundant.
5. Retire your glue services one at a time, verifying each against real traffic for a week.
6. Delete the code. The saving is not just the subscription; it is the repository you no longer maintain.
7. Keep the pipe for any genuinely non-chat real-time surface — partial migration is a good outcome.

The 30-second version

A socket is the easy 15%. History, replay, unread counts, receipts, moderation, push fan-out and media delivery are the other 85%, and you own all of them forever on a raw pipe. Count the services you have built before you compare subscriptions.