Three things change at once (the odds, the bet slip and the wallet), and the product is only trustworthy if a user never catches them disagreeing.
Real-time
Odds and match state
streamed, not polled
Crypto
Wallet and payouts
crypto-first balances
2
Product surfaces
sportsbook and in-house casino
The problem
Real-time is not a feature of this product, it is the product. Odds move, matches progress, balances change, and all of it happens while the user is mid-decision.
That breaks the usual request-and-response model completely. It also creates the real risk: if the bet slip, the wallet and the live market disagree for even a moment, the user has watched the platform contradict itself about their money.
What we did
The client is React and Next.js with Tailwind, built around streaming updates over WebSockets rather than fetching on interaction. Python services sit behind it.
Most of the difficulty is consistency under motion: keeping the bet slip, the wallet balance and live market data agreeing with each other while all three are being updated independently, and keeping the interface responsive at that update rate rather than re-rendering the page every time a number moves.
The outcome
Odds, match state and balances stream live across the sportsbook and casino, with the bet slip and wallet staying consistent through the update rate.
Frontend
Real-time
Backend
What we learned
When the data never stops moving, the architecture question is not how to fetch it but how to reconcile it. Pick one source of truth and make every surface read from it.
Scope your re-renders early. On a streaming interface, the naive approach is fine in development and unusable at production update rates.
Thirty minutes with the engineer who would lead the project. You will leave with an opinion on what to build, what to skip, and roughly what it costs, whether or not you hire us.
2 build slots open · Next start: early next month
What happens next