Realtime Features: Decide First, Then Build

Live updates, chat, presence, AI streaming or multiplayer: a WebSocket is a week to open and years to run. We start with a short fixed-price decision on whether your feature needs one at all, which transport and which platform (Vercel Functions, API Gateway, AppSync Events or a managed service), and what it will cost at your usage. Then, if you want, we build it.

Overview

Realtime features are where small teams most often take on more than they meant to. Opening a WebSocket is a tutorial; keeping thousands of them correct through deploys, mobile networks, reconnects and a second server instance is an ongoing system. Often the feature didn't need one: a poll every 15 seconds or a server-sent event stream does the job with none of that. Sometimes it does, and then the design decisions made in the first week decide the next two years.

Phase 1: the decision (fixed price, about a week)

• Walk through each realtime feature you have or want, and what "live" actually has to mean for it

• Pick a transport per feature: polling, server-sent events, WebSockets, or a managed service such as Ably, Pusher or Liveblocks

• Pick a platform: Vercel Functions, API Gateway WebSocket APIs, AppSync Events, a container service, or the managed service

• Model the monthly cost at today's usage and at ten times it

• A short written recommendation you can act on with or without us

Phase 2: the build (optional)

• Connection handling with reconnect, resubscribe and catch-up from a durable store

• Authentication and authorization that hold over long-lived connections

• Fan-out across instances through Redis, AppSync Events or a managed service

• Load tests for connection storms and fan-out, and dashboards for what matters

• A runbook for deploys, incidents and scaling

Deliverables

• The decision document and cost model

• If built: the code in your repository, tests, dashboards and runbook