A clean hit failed to register, then the session began rubber-banding. Kenji and I had been playing indie multiplayer games through most of 2024, not hunting for a business idea. We were doing other work, but kept finding the same pattern: good games from small teams that cared deeply, yet shipped with broken networking.
The failure is difficult to grasp until you see it. A session loads, the game looks polished, and the mechanics seem promising for 30 seconds. Then a player from another country joins and the world rubber-bands. You land an obvious shot, see the hit markers, and get no kill. Or a competitive match ends and the final score reveals that your session differed from everyone else's because it desynchronized midway without anyone noticing.
We began asking developers directly, at game jams, in Discord servers, and on forums. The replies lined up with surprising consistency.
The Pattern Kept Repeating
Teams shipping broken multiplayer were neither foolish nor inexperienced. Most were small, three to eight people, and highly skilled in the work they valued: art, design, and core mechanics. Networking was necessary, but unrelated to what made their game enjoyable to build, so it was the part they least wanted to make.
Their choices were limited: a general-purpose relay handling connections but not lag compensation; a middleware SDK needing deep integration and substantial configuration knowledge; or a from-scratch build. For lag compensation and anti-cheat, that last option could consume months before one line of game content shipped.
Most chose one of the first two options, then shipped whatever survived local tests. Those tests reveal little about real network conditions. With everyone nearby, latency is 0ms to 5ms. Real players connect from Bangkok, Singapore, and Tokyo with 80ms to 120ms between them. The behavior changes completely, and discovering that after launch is too late.
The Missing Piece We Kept Seeing
Every discussion kept exposing the same gap: adaptive lag compensation, handling each player's network conditions instead of applying one static model. Static compensation assumes similar latency. When that assumption fails, the poorly connected player may feel fine while everyone else sees a rubber-banding ghost.
With per-player adaptation, the server continuously profiles each connection and sets each compensation window separately. That makes heterogeneous groups feel far better. The technique is not new; large studios have used it for years. Small teams face the implementation cost: server logic must run beside the game simulation, retain state per player, and send corrections through the netcode layer. That is a major investment for a team shipping a game.
Anti-cheat was the other recurring gap. The studios we spoke with had no server-side cheat detection. Some depended solely on client checks that a motivated player could bypass. Others had simple anomaly detection for movement-speed outliers, but nothing covering behavior across sessions or the signal-processing demands of aimbot detection.
Their lack of action was not indifference. A real anti-cheat system is a full engineering project competing with game features.
Why We Chose to Build It
Before this, Kenji had spent several years on real-time sync systems, especially where determinism and latency demands were strict. Adaptive netcode presented familiar technical problems in a new domain. I had shipped multiplayer titles on mobile and PC, and had met each failure from the other side: as the developer fixing a session-sync bug the week before launch.
We began making the SDK we would have wanted: integration in hours rather than weeks; a server layer that automatically handles adaptive per-player compensation without making studios learn the algorithm; server-side anti-cheat requiring neither a client install nor a kernel driver; and pricing a three-person studio could afford instead of an enterprise contract with minimum commitments.
We are not claiming to replace every option. Good general-purpose networking libraries exist, as do large-scale anti-cheat providers for titles with millions of players. Our target is the middle: studios with real games, real players, and real competitive-integrity needs, but without the engineering budget to build or the revenue scale to warrant enterprise tools.
Where We Are Headed
Tashi entered early access in 2025. Its core SDK includes adaptive lag compensation, server-authoritative validation, and the five-signal anti-cheat detection layer covered elsewhere in this devlog. Small studios can begin free and remain free during development or early access, then move to paid tiers once players and revenue support them.
We are a small team, and we do not hide that. We can turn quickly on feedback from studios we work with, remain available for integration questions in ways a larger ticket-driven company cannot, and choose based on what helps studios ship better games rather than what suits a roadmap designed for another customer size.
We built Tashi for the same reason we are publishing this devlog: we kept meeting a solvable problem that remained unsolved for the studios needing help most. That was enough reason for us to try.
Learn how Tashi works, or start building on the free tier. No credit card required up to 50 concurrent players.