Esquadify is a competitive gaming platform that brings match creation, live streaming, wagering, and automated settlement into one connected experience. Players can challenge each other to head-to-head matches, stake ranked belts and prize money, and broadcast their matches live while spectators interact through real-time chat and gifting. The platform securely holds stakes throughout the event and releases them only after the result is verified, with a dispute process for contested or unanswered outcomes. Built over roughly a year, the platform combines a four-tier belt economy, real-time streaming, token-based payments, player statistics, and serverless infrastructure into a complete competitive gaming experience.
Milad came to TechEniac with a picture of competitive gaming that the existing tools only half-served. Tournament platforms organise brackets but don't broadcast. Streaming platforms broadcast but have no stake in the outcome. Wagering between players happens constantly and gets settled on trust, screenshots, and whoever argues hardest in a group chat.
Esquadify was built to be all three at once: the place a match is arranged, the place it is watched, and the place it is settled. Players challenge each other to head-to-head matches, stake ranked belts and prize money on the result, and broadcast the match live to an audience that can chat and send gifts while it happens. The platform holds the stakes from the moment a challenge is accepted and releases them only once a result is verified.
Development ran for roughly a year, covering the belt economy and event lifecycle, the OBS and streaming pipeline, real-time chat and gifting, dispute resolution, and the token and payout system underneath it all
Competitive gaming becomes significantly more complex when matches involve real stakes, live audiences, and player rankings. Esquadify needed to replace informal wagering and fragmented streaming workflows with a platform that could securely hold stakes, verify match outcomes, control broadcasts, and keep live audiences engaged while ensuring every event reached a reliable final state.
When two players agree a match is worth something, the money and the belts sit with the players right up until someone has to hand them over. The loser has every incentive to stop replying, and there is no neutral party holding anything. Any platform that arranges the match but leaves settlement to the players has skipped the part that actually goes wrong.
A player who wants their match watched has to configure OBS, start the stream, then keep half an eye on it - muting a mic, switching a scene, checking they are actually live - while playing a match they have money riding on. Every one of those actions means leaving the game. The tooling to broadcast and the place the match is happening were two different windows.
A player saying they won is fine right up until the moment it matters. Once a prize pool is attached, one side's word cannot be what releases it, and the platform needs a way to tell the difference between a result both players agree on, a result they contest, and a result only one of them ever submits.
If winning raises a player's standing but losing costs nothing, standing stops measuring skill within a few weeks and starts measuring how many matches someone has played. For a competitive ladder to hold its shape, a loss has to cost something real - which means the ranking system and the wagering system have to be the same system.
Player-created events for any game, where the creator sets the belt tier, the stake, and whether spectators watch free or pay tokens to attend
Stakes locked into the event before the match begins, so neither player is trusting the other to pay up afterwards
Broadcast controls inside the platform, so a player can mute, switch scenes, and manage their stream without alt-tabbing out of a match
A live room rather than a video feed, with real-time chat and gifting running alongside the stream
Two-sided result submission with a real dispute path and human adjudication for contested outcomes
A four-tier belt economy with automatic promotion and a genuine cost to losing
A permanent record of past events, their chat, and their results, aggregated into player statistics
A clean boundary between real money and platform currency, with card purchase on the way in and a reviewed payout on the way out
Esquadify does not hold a catalogue of supported games with fixed formats. A player names the game, picks which of the four belt tiers the match is fought at, sets how many belts each side is putting up, and chooses the spectator model: a public event anyone can watch free, or a paid event where the creator sets a token price at the door. The result is a platform whose inventory of matches is defined entirely by what its players actually want to play, with stakes calibrated by the people taking the risk.
Accepting a challenge is the moment the stakes stop belonging to the players. Both sides' belts and prize money move out of their balances and are held against the event itself for the duration of the match. Neither player can spend, gift, or withdraw what they have put up, and neither can quietly walk away from it. When the event settles, the stake moves from the event to the winner - it is never in two places, and it never depends on a losing player choosing to pay. On paid events, the tokens spectators pay at the door are split between the two players, so an event that draws an audience is worth more to both competitors.
The platform connects directly to the player's own OBS installation over obs-websocket v5 and exposes its controls inside the event page. Mute and unmute, switch scenes, toggle sources, start and stop the broadcast - the actions a player would otherwise alt-tab for sit on the same screen as the match. Commands apply to OBS immediately over the socket, and changes the player makes inside OBS come back the other way, so the panel reflects what the software is actually doing rather than what the platform last asked it to do.
The broadcast itself goes out the conventional way. OBS pushes over RTMP, authenticated with a stream key issued by the platform, into AWS IVS, which handles ingest and low-latency distribution to every spectator in the room. Keeping ingest on a standard protocol means any OBS setup a player already has works without modification, while IVS absorbs the delivery and scaling problem.
When the match ends, each player submits who won. If both name the same winner, the event settles and the stake releases immediately. If they name different winners - or if one player submits and the other never does - the event escalates to dispute rather than resolving on one side's word. In a dispute, each player files a written account and uploads an image as proof, which goes to an administrative review queue where an admin decides the winner. The stake stays locked throughout, so there is no window in which a contested result has already paid out
Belts are Esquadify's measure of standing, and they are won and lost rather than only accumulated. Winning takes the opponent's staked belts; losing hands over your own. Promotion is automatic and cascading - ten bronze consolidate into a silver, ten silver into a gold, ten gold into a platinum - and the cascade resolves all the way through in a single settlement, so a win that lands a player on a hundred bronze converts straight to a gold rather than stepping through the tiers one at a time. Image name - profile
Finished events close into an archive that keeps the result, the participants, and the chat that ran alongside the match. Each player's profile aggregates that history into the figures that matter competitively: wins and losses, events created, times challenged, and current belt and token holdings - answering the question an opponent is actually asking before accepting a challenge.
Browser-Side OBS State Drifting Out of Sync
The control panel talks to OBS on the player's own machine, but it is not the only thing doing so — the player has hotkeys and OBS's own window. A panel that flips a mute toggle simply because it sent a mute command drifts from reality within minutes, and a player mid-match ends up trusting an indicator that is quietly lying. The interface was built to never treat its own command as confirmation: a control sends its request and waits for the corresponding event back from obs-websocket v5's event stream before changing what it displays. On connecting, the panel pulls full current state and hydrates from it, so it opens matching whatever OBS is already doing. A dropped socket surfaces as an explicit disconnected state rather than leaving controls that look live but reach nothing.
Concurrent Stake Locking on a Distributed Databas
Accepting a challenge is not one write. It debits the challenger's belts, debits the opponent's, moves the prize money, credits it all to the event, and flips the event's status. Written as a plain read-then-write sequence on DynamoDB, two taps from two devices — or one Lambda invocation retried after a timeout that had actually succeeded — can both read the same starting balance and both write from it, creating belts and prize money that exist twice. Every balance change was made a conditional write predicated on the value it read, and the event's status transition conditional on the event still being in a state that permits accepting. The first request through wins; the second fails its condition and is rejected rather than blindly retried. Where several items must move together, they are grouped as a single transactional write, so the whole accept either lands or none of it does.
Multi-Tier Belt Conversion Interrupted Mid-Cascade
Ten bronze become a silver, ten silver a gold, ten gold a platinum. The obvious implementation is a loop — convert a tier, check again, convert again — and it is wrong on a serverless runtime. A player who wins their way to a hundred bronze needs two full passes through the ladder, and any invocation that times out or is interrupted between passes leaves that balance visibly, possibly permanently, mid-conversion. Conversion was made a calculation rather than a process: the incoming total resolves to its final four-tier balance in a single pass, written as one conditional update in the same operation that awards the win. A hundred bronze resolves straight to a gold in the write that awarded it, and there is no intermediate state to be caught in.
Stateless Compute Serving Stateful Live Rooms
Everyone watching a match holds an open WebSocket connection, and a gift or chat message has to reach all of them within a moment of being sent. But the Lambda handling that message is a fresh, stateless process that knows nothing about who is in the room, and rediscovering the audience from scratch on every message does not hold up when chat and gifts fire continuously through a live match. Connection identity was moved out of the runtime entirely: on connect, the connection is registered against its event room, with Redis holding the hot room-to-connections mapping so a fan-out is one lookup rather than a scan. Disconnects clear their own record on the disconnect route, and connections that vanish without one are pruned when a send to them comes back gone. Delivery then costs in proportion to the size of the room, not the size of the platform.
Unresponsive Players Freezing Prize Pools Indefinitely
Two cases are straightforward: both players name the same winner and the event settles, or they name different winners and it is a dispute. The third case quietly breaks the model — one player submits and the other never opens the app again. A system that waits for two submissions leaves that stake locked forever, and one that awards the win to whoever submitted first rewards speed rather than the actual result. Silence was made a form of disagreement rather than a forfeit: an unanswered result escalates into exactly the same dispute queue a contested one does, where the submitted account and proof image go to an admin who decides the outcome. Every event therefore has a terminal state that does not depend on both players cooperating, and no player can protect a stake they have lost by refusing to acknowledge the match happened
Year
of Continuous Product Development
Belt Economy
with Automatic 10:1 Cascade
DynamoDB Tables
Powering the Platform
Real-Time Channels
per Live Match support spectator chat/gifting and browser-based OBS contro
Frontend
Backend Runtime
Data & Caching
Real-Time & Streaming
Payments & Integrations
MediaTech / EntertainmentTech
AI-powered music interpretation platform helping Spanish-speaking audiences discover songs, explore lyrics, and understand the stories behind them.
TravelTech / Tourism SaaS
AI-powered business intelligence and operations platform for tour operators. Unified bookings, analytics, CRM, customer communication, marketing, and automation in one connected system.
