Real-time web application development.
Live dashboards, streaming feeds and push updates that hold up under real conditions.
Real-time is the feature that demos beautifully and then falls over in production. The demo has one user on office wifi. Production has hundreds on mobile networks, all reconnecting at once after a blip, while an upstream feed sends a burst that is faster than your clients can render. Building this properly is mostly about the failure cases.
What’s included
- Live dashboards that update without a page refresh
- WebSocket and Socket.io services with room-based targeting
- Continuous ingestion from external feeds and APIs
- Push notifications to web, email and messaging channels
- Reconnection with state resynchronisation
- Backpressure handling so slow clients cannot stall the service
- Monitoring and alerting for a service that must stay connected
What actually goes wrong
Clients disconnect constantly on mobile. If reconnection does not resync missed state, users silently see stale data and trust the product less. Broadcasting to every connection does not scale past a few hundred users. And if your ingestion is faster than your delivery, memory grows until the process dies. Each of these needs a deliberate decision, not a default.
A worked example
I built a platform that watches the Bitcoin mempool for large transfers, classifies the wallets involved, and pushes signals to a live dashboard and a Telegram channel within seconds of a transaction broadcasting. The hard parts were not the WebSocket layer — they were staying connected to upstream sources that drop you, and not double-sending a signal after a reconnect.
When you do not need real-time
Plenty of dashboards described as real-time only need to be current within a minute, which polling handles at a fraction of the complexity and cost. I will tell you when that is the case.
Common questions
How many concurrent users can it handle?
That depends on message volume and payload size more than user count. I will size it against your actual expected load and tell you where the ceiling is and what raising it would cost.
Can you add real-time features to our existing app?
Usually yes, as a separate service alongside your current application rather than a rewrite of it.
What happens if the connection drops?
The client reconnects with backoff and resynchronises the state it missed, so the user does not silently see stale data. This is the part most implementations skip.
Can you push to Telegram, Slack or email as well?
Yes. A web dashboard plus one messaging channel is a very common combination, and I have built exactly that.
Have a project in mind?
Tell me what you're building and roughly when you need it. I reply to every genuine enquiry within one working day.