Historical Project Outcomes at a Glance
- Longer engagement: Historical Google Analytics data showed visitors staying for minutes rather than seconds.
- Performance: The implementation achieved a 90+ Lighthouse score during the engagement.
- Content operations: Structured Sanity content and documented publishing automation reduced recurring manual content work.
- Commerce connection: Store and product pages connected the interactive brand experience with Snipcart commerce.
These results describe the historical project period and were not remeasured during the later portfolio review. This case study is grounded in preserved source code, genuine project media and historical project records. Where an earlier publishing or deployment mechanism is documented but no longer present in the preserved source snapshot, I describe the behavior at that level rather than reconstructing missing implementation details.
1. The Product Problem: Give Brand Interest Somewhere to Go
Bonus Pool needed to serve visitors whose interest in the artist existed before purchase intent. A conventional merchandise page could handle someone who already knew they wanted a product, but it offered very little to a visitor who arrived because of the music, visual identity, tour activity or broader world around the brand. The product therefore needed several meaningful ways to spend time before commerce became relevant.
The solution was a Windows 98-style Web OS where music, dates, posts, photos and a playable Minesweeper game live inside one branded desktop. The visual language is nostalgic, but the product decision underneath it is practical: instead of forcing every visitor through the same page sequence, the application gives them a set of activities and allows them to decide what to open next. Commerce remains available through dedicated merchandise and product routes without becoming the organizing principle for every interaction.
That experience created a second problem behind the interface. Songs, shows, posts, photos and products all change on different schedules, while the mechanics of the desktop, window movement, audio playback and game state should remain stable. Content management therefore needed a separate operational boundary from interaction logic. As main developer, I connected those concerns in one application: a stateful Web OS, structured Sanity content, a Qwik and Netlify Edge delivery architecture, and a Snipcart-backed commerce surface.
2. A Desktop Is an Application State Problem
The Windows 98 treatment could easily have remained a visual gimmick. The engineering work began when the desktop had to behave like one.
Every open window needs an identity, coordinates and a place in the stacking order. Selecting one should bring it forward without destroying the others. Dragging needs to work consistently across different kinds of modules. Closing a window should remove only that instance, while opening a track, post or photo may create another window with its own content. At the same time, the modules themselves carry very different state: the audio player tracks media playback, the calendar tracks the selected date, and Minesweeper maintains a board, timer and game status.
I implemented those responsibilities around a shared widget collection. New windows receive incrementing IDs and carry the type, label, coordinates and content required by the module they represent. Selecting a window promotes it by changing its position in the collection, mouse and touch drag handlers update its coordinates, and the close action removes the matching instance. The desktop owns these common rules, while the module inside each window owns the state specific to its behavior.
That separation is what makes the interface coherent. Music can open a list of tracks and launch a player. Posts can open a list and then create another window for the selected article. Photos can move from a collection into a viewer. Dates and Minesweeper can expose their own interactive state without implementing another version of window promotion, dragging or closure.
The result is visible in the multi-window state below. Several modules remain present at the same time, including a played game, music, editorial content, photos and the calendar. The visitor is interacting with one environment whose internal activities can coexist rather than a sequence of pages where each navigation step replaces the previous one.
3. Giving Individual Modules Enough Depth to Matter
The desktop model only works if the modules inside it offer real interaction. A collection of decorative folder icons would create the appearance of an operating system without giving visitors much reason to remain inside it. Music and Minesweeper are useful examples because they place very different state machines inside the same shared window environment.
The music player uses an audio element and local state for current playback time, duration, loading state and whether the track is playing or paused. Media events update the visible timeline, while Play, Stop and volume controls act on the player directly. The source also includes an analyser-driven canvas visualization, giving the module its own visual behavior without pushing those concerns into the desktop-level state model.
During historical live inspection, playback time continued advancing while Posts was opened. That behavior demonstrates why the separation between desktop coordination and module-specific state matters: opening another activity can add a window to the environment while the player remains active, instead of treating every content action as a full replacement of the current experience.
Minesweeper applies the same architecture to a completely different interaction model. The game maintains tiles, neighboring-mine counts, reveal and flag behavior, a timer, and idle, playing, won or lost status. Clicking a tile changes the board and can change the state of the game; a finished board disables further interaction until the visitor starts another round.
The game matters to the case study because it demonstrates that the product is doing more than presenting content in retro-styled containers. Bonus Pool combines passive media, editorial browsing and active play inside the same application model, while allowing each of those modules to keep the internal behavior it needs.
4. Entering the Environment Was Part of the Product
The desktop metaphor begins before the visitor reaches the desktop itself. Bonus Pool uses a BP OS loading sequence built around a black screen, pixel-art mark, progress indicator and staged messages including Loading Manifestation, Initializing Dream Sequence, Programming Environment and Launching Reality. The sequence eventually transitions into the full environment with Music already open.
Genuine BP OS loading sequence transitioning into the interactive desktop.
In the application, the loader follows a timed client-side progression, so the percentage and staged messages are part of the branded entry experience. This turns the transition itself into an introduction to the product's operating-system metaphor rather than treating loading as an unrelated technical state.
5. Performance Architecture for Uneven Interaction
Bonus Pool contains a large amount of optional behavior. One visitor may only listen to a track, another may open several posts and photos, and another may spend most of the session inside Minesweeper. Building the interface as though every possible interaction had to become fully active at initial page entry would work against the actual usage pattern of the product.
Qwik was a good fit for that constraint because its resumable model reduces the need for a conventional full-page hydration replay. The application can begin from server-rendered HTML while interaction code becomes relevant as the visitor engages with the interface. Netlify Edge supplied the server-rendering and HTML-delivery path, with the Vite configuration producing the server entry used by the Netlify function.
The implementation achieved a 90+ Lighthouse score during the engagement. That result is useful in the context of this project because the interface deliberately carries more application state and interactive behavior than a conventional artist landing page. Performance architecture had to coexist with the product's ambition rather than being achieved by removing the interaction that made Bonus Pool distinctive.
The architecture separates four major responsibilities: structured content, application delivery, interactive experience and commerce. That separation is important because each layer changes for different reasons. Editorial records change when the brand publishes something new, application code changes when interaction behavior evolves, delivery infrastructure changes for performance and deployment concerns, and the commerce service exists to handle shopping responsibilities that do not need to be rebuilt inside the Web OS.
6. Content as an Operational System
The visible desktop is only one side of Bonus Pool. Behind it, Sanity provides the structured content model used by the application. The preserved schemas cover songs, shows, posts, photos, products, variants, venues, categories and shared site configuration, giving each content type fields appropriate to the way the product consumes it.
Songs reference titles, dates and audio files. Shows carry start and end dates, status, venue relationships and ticket links. Posts and photos contain their editorial metadata. Products include default and additional variants, while site configuration holds shared information such as titles, descriptions, social links and marquee content. This structure allows the application to reason about the material as data rather than embedding editorial content directly into the Web OS implementation.
The query layer then selects the records required by each surface. During server rendering, the desktop receives songs, shows, posts and photos that become inputs to the interactive modules. Store queries retrieve merchandise previews and product counts, while product queries resolve an individual item and its variants. The application controls the way a window opens, moves or behaves; Sanity controls the content available to that window.
Conceptual publishing-to-module flow based on the preserved application queries and state model.
That boundary reduces recurring frontend work. Publishing another song can change what the Music module presents without changing player controls. Adding a post can change what visitors find inside Posts without modifying the window system. Updating show information can change the calendar data without changing the logic that allows the calendar window to coexist with the rest of the desktop.
Historical project records also document publishing automation and date-freshness work that reduced recurring developer involvement. The preserved source snapshot clearly establishes the Sanity schemas, application queries and module-level content flow shown above, while the earlier deployment hooks behind the documented publishing automation are no longer part of that retained source. For date-based content, the calendar works from structured show records, groups information around a selected day and distinguishes past and future dates.
The broader architectural point is that editorial work and interaction engineering have separate responsibilities. That makes the unusual frontend easier to maintain because adding or changing content does not require the brand to reopen the mechanics of the Web OS itself.
7. Connecting Exploration to Commerce
Commerce is a real part of the application rather than an external link attached to the experience. Bonus Pool includes a merchandise route that presents Sanity-backed product previews and dedicated product pages that resolve the selected item, its imagery and available variants.
On the product surface, visitors can select a variant and quantity while the interface updates the relevant imagery and displayed pricing. Snipcart supplies the Add To Cart and checkout infrastructure, which gives the application a useful boundary: Bonus Pool owns product discovery and product interaction, while the commerce service handles the shopping infrastructure that does not need to be custom-built into the desktop.
The integration is also loaded according to the same principle used elsewhere in the architecture. Snipcart is configured with an on-user-interaction loading strategy plus a five-second timeout fallback. The full commerce library therefore does not need to become part of the visitor's first interaction with the Web OS, while the fallback still ensures that commerce becomes available even if the expected interaction trigger does not occur.
This matters because purchase intent is only one possible state in a Bonus Pool session. A visitor can arrive to listen, browse, read or play before deciding whether merchandise is relevant. The technical boundary allows that exploratory experience and the commerce surface to coexist without forcing the entire application to behave like a storefront from the first request.
8. From Entry to Commerce
The architecture becomes easier to understand when the pieces are followed as one possible visitor lifecycle. A visitor first encounters the BP OS transition and enters the desktop, where Music is already available and the launchers expose Dates, Posts, Photos and Mines. Opening one of those launchers creates a module inside the shared window model, while selecting a track, post or photo can create an additional content-specific window.
As the visitor continues exploring, the desktop coordinates identity, coordinates, stacking and closure for the active windows, while each module preserves the state needed for its own behavior. Sanity-backed records supply the music, posts, photos and show information displayed by those modules, which means the experience can change editorially without changing the interaction model that presents it.
When buying becomes relevant, the visitor can move into the merchandise and product routes. Those pages resolve Sanity-backed product records and expose product imagery, variants, pricing and quantity controls. The Add To Cart integration then passes responsibility into Snipcart's commerce layer. Listening, editorial browsing, play and merchandise therefore belong to one product ecosystem even though the architecture assigns them to different technical responsibilities.
That separation is one of the more important qualities of the system. Bonus Pool does not depend on every visitor following the same sequence, and it does not require one subsystem to own every stage of the experience. The Web OS creates a coherent place to explore, the content layer keeps that place supplied with material, and commerce becomes available when the visitor's intent reaches that point.
9. Why These Architecture Decisions Mattered
The architecture choices were valuable because they supported specific characteristics of the product rather than because the technologies were novel in isolation.
The shared desktop state gives the Web OS one consistent model for window identity, promotion, coordinates and closure. Without that common layer, each module would need to recreate the mechanics of the desktop, increasing the chance that Music, Posts, Photos, Dates and Minesweeper would feel like separate components wearing the same visual skin.
Module-specific state keeps the opposite problem under control. Audio playback, calendar selection and game progress do not belong in one oversized global state object simply because they appear inside the same desktop. Each module owns the behavior that makes it useful, while the shared shell handles only the responsibilities common to every window. That division makes the application easier to reason about and allows the product to add depth without turning the desktop coordinator into the implementation for every feature.
Qwik and Netlify support the delivery side of that model. Many of the available interactions are optional during any individual session, so a resumable application architecture fits the product better than assuming every possible module will immediately become active. The historical 90+ Lighthouse result provides evidence that the interactive ambition and the performance strategy were able to coexist during the project.
Sanity solves a different operational problem. The artist's songs, shows, posts, photos and merchandise will change more frequently than the interaction mechanics of the application. Keeping those records in a structured content system means editorial changes can flow into the experience without coupling routine publishing to the code that implements window dragging, media controls or game behavior.
Snipcart provides a similarly clear boundary for commerce. Bonus Pool needed store and product functionality, but building a custom checkout stack would have added a separate financial and transactional responsibility to a product whose distinctive engineering value was elsewhere. The application therefore owns the branded discovery and product-selection experience, while Snipcart handles the commerce infrastructure. Delaying that integration until interaction or the fallback timeout also keeps the commerce dependency aligned with the fact that many visitors may spend part of their session elsewhere in the experience.
Together, these decisions create a system where the product's personality and its operational requirements reinforce each other. The pixel-art desktop is supported by real application state, the content inside it can be managed independently, performance remains part of the delivery architecture, and the path to merchandise exists without forcing every part of the experience into a commerce-first design.
10. Historical Outcomes and Business Impact
Historical Google Analytics data showed visitors staying for minutes rather than seconds. That outcome matters because longer exploration was one of the central product goals: the application gave visitors several meaningful activities before purchase intent became the only reason to remain on the site. The historical data does not provide an exact average duration or attributable conversion increase, so I keep the claim at the level the project evidence supports.
The implementation also achieved a 90+ Lighthouse score during the engagement. For a state-heavy frontend with movable windows, media controls, game logic and several content surfaces, that result helped validate the decision to treat delivery architecture as part of the product rather than something to optimize after the experience had already been built.
Sanity-based content management and the project's documented publishing automation reduced recurring manual content work by separating editorial updates from application development. The brand could change songs, posts, photos, shows and merchandise without treating every update as another frontend implementation task.
Bonus Pool also connected that engagement environment with a real merchandise and product system backed by Snipcart. I do not attribute a conversion, revenue or acquisition-cost improvement to the project without corresponding measurements. The documented outcomes are stronger engagement, strong delivery performance, reduced recurring content-maintenance work, and a working path from the interactive brand environment into commerce.
11. What This Project Demonstrates
My role as system architect covered the parts of Bonus Pool that had to work together for the concept to become a real product: the custom frontend interactions, shared window model, module-specific media and game behavior, Sanity integration, publishing workflows, product and commerce integration, performance architecture and deployment.
The project is useful in my portfolio because its visual distinctiveness could easily obscure the systems work underneath it. The Windows-style environment only succeeds because the application has a coherent model for coordinating independent activities. Music remains a real player with its own lifecycle, Minesweeper remains a real game with its own state, and editorial modules remain driven by structured content rather than hard-coded screens. Those pieces can coexist because the shared desktop owns only the rules that need to be common across them.
The same separation continues beyond the desktop. Sanity provides a maintainable content boundary, Qwik and Netlify support the delivery model, and Snipcart supplies commerce infrastructure when visitor intent reaches merchandise. The result is an interactive product where brand experience, application state, content operations and commerce remain distinct responsibilities while still feeling like parts of one system.
Explore the live Bonus Pool experience · View the concise Bonus Pool project overview
If you're building an interactive product where content, application state and commerce need to work together, let's discuss the system.