product software
SlurpNet Launcher
A desktop application for game discovery, installation, updates, release channels, service status, and player onboarding.
Challenge and constraints
Players needed one reliable entry point instead of scattered setup instructions, downloads, and status information.
Constraints
- Protected feed and signing details cannot be published
- Public release state stays separate from live runtime state
- Windows and Electron behavior must be proven on the delivery surface
What I owned
Product requirements, player workflow definition, systems integration, release acceptance, and Windows/browser quality assurance.
Ownership
- Define player workflows
- Direct systems integration
- Own release acceptance
- Review Windows and browser behavior
Decisions and implementation
The decisions define the boundary; the implementation records what was delivered inside it.
Decisions
- Use signed versioned release metadata
- Separate public release state from live runtime state
Implementation
- Game catalog and detail flows
- Versioned release and channel state
- Install, update, and repair visibility
- Safe service-status integration
Validation
Evidence is checked against the surface it is meant to demonstrate.
Checks
- Desktop browser-equivalent capture
- Windows launcher proof
- Feed-coherence checks
Evidence-backed outcomes
Each delivered result is paired with the public proof basis that supports it.
- Centralized discovery, installation, update state, and onboarding in one desktop entry pointBasis: Shown across the launcher home, game-detail, release-state, and walkthrough evidence.
- Established a repeatable signed-release and feed-coherence pathBasis: Explained in the release pipeline and verified through feed-coherence checks.
- Made managed update state visible to playersBasis: Shown in the release-state capture and end-to-end walkthrough.
Evidence gallery
Each artifact is selected for what it explains and reviewed for public safety.



