Revenue-share HTML5 game hub embedded into the Prachyam OTT platform via Flutter WebView and React

The Prachyam platform's subscription revenue came from content. Content requires production budget. The math that limits every OTT platform at scale — producing enough content to justify a subscription — is the same math that limits one at Prachyam's stage. The question was whether there was a way to extend time-on-platform and generate supplementary revenue without the production overhead of creating more content.
Gamezop operates a revenue-share model: they maintain a catalogue of over 100 browser-based HTML5 games, you embed the catalogue in your platform, users play, ad revenue from game sessions splits between Gamezop and the platform operator. Zero game development cost. Zero content production overhead. The catalogue is maintained by Gamezop; the integration is a surface problem.
The insight from the Rishi Talks work applied here directly: Gamezop confirmed that games are a viable secondary revenue layer on a content platform. The difference is that Rishi Talks surfaced that insight through observation; this integration acted on it directly.
Flutter WebView wraps the Gamezop HTML5 game catalogue for iOS and Android. The WebView initialises with authentication context — a token passed to the Gamezop URL at load time — so the user lands directly in the authenticated game lobby without a separate login flow. Session continuity matters here: if the user has to log in twice (once for Prachyam, once for Gamezop), the friction reduces the likelihood they try the games at all.
The React web client uses an iframe-based embed with the same authentication handoff at iframe initialisation. The web implementation is structurally simpler than the mobile WebView — an iframe has browser-native security boundaries and requires less lifecycle management than a WebView inside a Flutter widget tree.
Revenue from game session display ads flows back under the standard Gamezop revenue-share agreement. No custom backend required: Gamezop handles session tracking and payout reporting on their end.
The engineering work here is not complex. The decision is the contribution. Identifying that a revenue-share HTML5 game catalogue is the correct tool for this use case — rather than building a games feature, licensing game assets, or ignoring the engagement gap entirely — is a product judgment that engineering skills made possible but didn't determine on their own.
Recognising when not to build, and what to integrate instead, is the skill that scales. Gamezop integration is that skill applied correctly.
Forensic stabilisation and feature expansion of a production streaming platform across web, mobile, and TV
Astrology app shipped to both stores in one day
OTT Platform — 9 Platforms, 1 Monorepo
Did this resonate?