Industry analysis and what was missing
Esports is a multi-billion-dollar industry, yet teams often struggle with fragmented tools and inefficient workflows. I myself experienced these challenges firsthand while working with teams.
Thus, the idea was born of a unified platform, that could also act as a cloud platform behind the scenes, being able to store user data efficiently and at scale, especially due to the immense potential growth of the app within the gaming sector.
Teams planned strategies across documents, presentations, and chat. I saw an opportunity to bring that work into one shared platform and took over the market gap.
Rainbow Six Siege is a Top 4 competitive esports title on PC, after a total prize-pool sum of $7,112,519 in 2026, known for its standing out tactical depth and team-based gameplay. Before Stratforge could grow in other games, it needed to establish a strong presence and workflow within this game first.
Turning plans into a team workflow
I built Stratforge as an idea around a multi-canvas application, where each canvas could represent a different aspect of a team's strategy, in this case its mostly "levels" of a particular game.
Stratforge is completely game-agnostic, meaning the app-code has no knowledge of games themselves, game data is managed by the Stratforge team using custom management tools.
Keeping game data separate from the core application made initial development more involved, but meant game updates could be managed without rebuilding the platform around each title.
What differentiated Stratforge from everything else
Stratforge is unique, as it not just owns its own Cloud Infrastructure, making it capable of handling large-scale data efficiently, but also features user-facing interfaces and experiences, that are the unique selling points of the platform. Like:
Creating teams, books, folders and customizing organized views that can be color coded, rearranged, and filtered. A truly custom experience.
Realtime and collaborative approach with live cursors and simultaneous editing (more about this in the Engineering Feat below).
Intricate permission management for controlling access of different team members to various parts of UGC (User Generated Content).
Advanced tooling, such as task assignments, progress tracking, follow mode, export pipelines to export folders deeply into organized PDF files with a few clicks, and so much more...
Teammates can see cursors and edits in real time, discussing and revising the same blueprint together. Everyone can follow changes as the plan takes shape.
Separate map views and round stages turn a strategy from a static image into a sequence of actions teams can review and refine. Each stage keeps its part of the plan easy to find.
Lineups, instructions, and assigned tasks connect each plan to the people responsible for carrying it out, keeping the team aligned in one workspace. Players can see what they need to do before practice begins.
Providing a truly unique and seamless user experience was sole reason why Stratforge's word of mouth spread rapidly. It is why $0 could be spent on marketing, but still have rapid growth.
Architecture and scale
I hand-built most of the product across frontend, backend, and realtime systems, then deployed and operated it on self-hosted infrastructure. I ran the closed beta for a year, taking responsibility for the product beyond implementation and through its day-to-day operation.
Fastify, Vike, React, TypeScript, Node.js, WebSockets, PostgreSQL, Redis, and BullMQ. I designed the collaboration architecture to scale horizontally across the stack with replicas. Made possible through stateless websocket servers, using Socket.io and a Redis adapter.
A collaborative canvas has to serve two different needs at once. It should feel direct and visual while people are editing, and it should preserve enough structure for a team to return to a plan later. The application brings map objects, stages, character and utility choices, task assignments, and written instructions into one product rather than presenting them as unrelated tools.
As Stratforge is asset-heavy, Cloudflare R2 is used as a global CDN, with excessive caching of assets and builds to maximize performance and reduce load times.
Next to the globally serving R2 CDN and global cache with layered tiered caching, images are optimized into .WEBP format, as it reduces load times but keeps quality intact.
Realtime collaboration
Live cursors and selections show teammates where others are working, while edits appear in the same shared plan. Players and coaches can review a tactic together and avoid passing around separate copies that need to be merged later.
To feel responsive, local edits must appear immediately and remote changes must reach collaborators with low latency. The system needs a bidirectional connection, ordered updates, and a way to recover from dropped or out-of-order messages and version conflicts without interrupting anyone's work.
CRDTs were an option, but I chose a custom optimistic concurrency protocol built around monotonically increasing versions. Clients apply updates in order and buffer any that arrive out of sequence.
The protocol: Buffering, reconciliation and rebase
When versions arrive in sequence, the client applies them without reconciliation. If a version is missing or out of order, the client buffers the update and fetches the latest server snapshot to reconcile its state.
Recovery path: when a version conflict occurs
When the server rejects an update, the client's version is behind the shared state. The optimistic edit stays visible while the client catches up in the background.
- The client fetches the latest server snapshot to reconcile its local state.
- It rebases pending local operations on the reconciled snapshot.
- It batches the rebased changes into a new command and sends it to the server.
- The server confirms the update, or the client repeats the cycle with exponential backoff if another conflict occurs.
Buffering alone was not enough to keep collaborators in sync. The client also needed a way to reconcile gaps and retry without discarding visible edits.
Production and operations
My CI/CD works on top of GitHub Actions, which is the obvious choice as it integrates seamlessly with the GitHub repository hosting the project.
A custom dedicated Hetzner instance is used, running Docker Compose to manage the application and enable rolling deployments with zero downtime. Binaries are built in the CI/CD pipeline, served through Docker Images and pulled in the deployment environment.
Deployment Considerations
I ended up deciding to go for a custom hosting solution, hosting on a Hetzner CCX23 instance using Docker Compose to allow rolling deployments (zero-downtime updates). The reasoning is quite simple:
-
Live multiplayer cursors, selections, presences and realtime updates require an active bidirectional connection. SSE are out, as they only support unidirectional communication from server to client.
-
Websockets are expensive to host on infrastructure not made for Websockets, as they require a serverful environment, other than Vercel that only offer serverless.
-
Custom hosting allows full control over the infrastructure, ensuring that the realtime requirements of the application are met without relying on third-party serverless limitations.
-
Budget constraints force a highly cost-effective hosting solution, making custom infrastructure a more viable option compared to serverless alternatives. As at this point, Stratforge isn't commercial.
I learned to scale and maintain a custom hosting infrastructure for a realtime collaborative application, balancing performance, cost, and operational complexity. Quite valuable.
Results
The closed beta grew to 3,077, who created more than 11,075+ strategic documents containing over 389,612+ objects. Those numbers reflect teams actively using the workspace to build detailed, structured ideas, not just signing up for an account.
3,077
Closed beta users
11,075+
Created documents
389,612+
Objects on documents
I learned to talk to professionals, gather feedback effectively, and iterate on the product based on real user needs. I talked to hundreds of users person to person and lead a small QA session.
The beta showed both demand for the product and sustained use of its planning workflow.
Stratforge grew through word of mouth, without paid marketing. I built and operated the product end to end, from engineering to infrastructure.