Sparkle — private realtime chat.

the problem

Realtime chat looks like a solved problem until it is your product. Messages have to arrive once, in order, and stay readable when a client reconnects. People need to know who is online without leaking more than they should. Abuse has to be handled before it is visible, not after a report. And all of that sits on top of a payment flow that has to be boring.

what we built

A Next.js product on a PostgreSQL data model, with realtime delivery, server-side authorisation on every channel, moderation tooling for the operators, a subscription flow, and one automated deployment pipeline. The pieces we treat as infrastructure — delivery, authorisation, billing — are the parts we refactored hardest, because they are the parts that hurt when they are wrong.

the decision that kept it simple

We kept the message core independent from the surfaces built on top of it. Matching, notifications and moderation read and write through the same core instead of each growing its own path — so a new surface ships without reworking delivery, and a delivery change does not quietly break three other features.

where it stands

Live and under active development. The product is public at sparkle.dating, and every release goes through the same pipeline.