Working with a backend developer, I built the PleaseFix MVP to test whether one product could connect player reports, moderator triage, and development-team tracking. I owned the complete React frontend, its design system, and its theming architecture.
Mapping the first product flow
PleaseFix was an MVP for reporting and tracking video-game bugs. A player could describe a problem, find an existing report, and vote for bugs they had encountered. This community signal helped surface issues shared by several people.
Moderators then had a triage flow for qualifying reports. Automation created or linked bugs in Jira so development teams could bring them into their usual tracking process.
One foundation for several games
The MVP had to test the journey with a small team: one backend developer and me on the frontend. It needed to cover very different users, from player to developer, without building a rigid solution around one game.
We needed a foundation that could be adapted across games. The interface, components, and themes had to change with each game universe, while reporting, voting, triage, and synchronization remained shared.
The frontend I built
I started from an empty project and built the complete React frontend. I developed the application foundation and interfaces needed by players and moderators, coordinating with the backend developer on the flow from report to Jira.
I also built the design system and a theming model based on design tokens. Colors, typography, and components could receive a different skin without duplicating the whole interface.
Tokens, themes, and handoff
Connect each role through one flow
The product followed a clear progression: the player reported or voted, the moderator triaged, then the issue was created or linked in Jira. Each interface exposed what its role needed while preserving continuity across the report.
Separate components from their appearance
The design system carried shared structure and behavior. Design tokens defined the visual identity of each version, allowing PleaseFix to fit several games without rewriting components.
Prepare the handoff during the MVP
The foundation had to remain understandable and extensible after the exploration phase. When a dedicated team took over the MVP, it could continue iterating with the same design-system, theming, and shared-flow model.
What the MVP enabled
The MVP established the complete product flow, from player reporting to Jira tracking. A dedicated team then continued development and adapted it to several games while reusing the foundations already in place.
I no longer have the details of the tests that preceded that handoff, so I do not attach a validation metric to it. The documented result is the continued use of the architecture and product principles in later versions.
The real subject of this MVP was a foundation that could change identity from one game to the next while keeping the same mechanisms.