The Problem: Brand Interest Before Purchase Intent
A visitor can be interested in an artist's world before being ready to buy merchandise. Bonus Pool needed to give that interest somewhere to go: listen to music, read a post, browse photos, check upcoming dates, or play a game.
Commerce still needed to remain part of the experience, but a product grid did not need to be the visitor's only meaningful destination.
There was also an operational constraint behind the interface. Songs, shows, posts, photos and merchandise change independently. The brand needed to manage that content without turning every editorial update into a frontend change.
The Targeted Outcomes
- Support longer exploration: Give visitors several self-directed activities inside one recognizable brand environment.
- Separate content from interaction logic: Model media, events and merchandise as structured records that the application can query.
- Connect exploration to commerce: Provide a real store and product flow backed by Snipcart when buying becomes relevant.
- Keep a state-heavy interface practical to deliver: Use an application and rendering model suited to optional, interactive modules.
The System: An Interactive Web OS
As main developer, I built Bonus Pool around a Windows 98-style desktop with pixel art, familiar launchers and a persistent taskbar.
Music, Dates, Posts, Photos and Minesweeper share the same environment, each giving the visitor a different way to interact with the brand.
Interaction State Behind the Desktop
The retro interface is visual, but the core engineering problem is application state.
Opening a module creates a window instance inside a shared widget collection. Each window has its own identity and position. Selecting a window promotes it in the stack, dragging changes its coordinates, and closing removes that instance.
Module-specific behavior lives inside those windows. The audio player manages media state, the calendar manages date selection, Posts and Photos can open additional content windows, and Minesweeper maintains its own board, timer and game result.
That model allows several activities to coexist instead of forcing every interaction through conventional page navigation.
Content and Commerce Architecture
Sanity supplies structured songs, shows, posts, photos, products and shared site configuration.
The Qwik application queries those records and renders the experience through Netlify Edge. The Web OS handles the interactive brand environment, while dedicated merchandise and product routes provide the commerce surface.
Product pages expose product imagery, variant selection, displayed pricing and quantity controls. Snipcart provides the Add To Cart and checkout infrastructure, giving commerce a clear boundary rather than requiring the Web OS itself to become a custom checkout implementation.
Performance and Content Operations
Qwik's resumable model was a useful fit for an interface where many interactions remain dormant until the visitor chooses to open a module. Netlify Edge handles server rendering and HTML delivery.
Commerce follows the same principle of loading responsibility when it becomes relevant. Snipcart is configured with an interaction-triggered loading strategy plus a timeout fallback, so the full commerce library does not have to load immediately when a visitor first enters the experience.
Sanity creates a separate operational boundary for content. Songs, shows, posts, photos and merchandise can change without rewriting the code responsible for window movement, media controls, game state or other interaction behavior.
Historical project records also document publishing and date-freshness automation that reduced recurring content-maintenance work. Those deployment details belong to the earlier project architecture, while the preserved source snapshot clearly establishes the Sanity content/query layer used by the application.
The Outcome: More Ways to Explore
Historical Google Analytics data showed visitors staying for minutes rather than seconds.
The implementation also achieved a 90+ Lighthouse score during the engagement, demonstrating that the unusual interface could coexist with a performance-conscious delivery strategy.
Bonus Pool ultimately connected music, editorial content, event information and play with a real commerce implementation. My ownership covered the custom frontend interactions, shared desktop state, media and game behavior, CMS integration, commerce integration, performance architecture and deployment.
The recorded outcomes here are longer engagement and strong delivery performance. I do not attribute a conversion or revenue increase to the project without corresponding measurement.
Explore the live Bonus Pool experience · Read the full Bonus Pool engineering case study