One platform where players discover, developers prove progress, and publishers read real traction.
The PlayFirst prototype: discovery, developer dashboard, game detail page, and trust signals across all three audiences in one system.
PlayFirst is a concept platform that helps unfinished indie games earn trust earlier by connecting player discovery, developer progress, structured feedback, and funding visibility in one system.
Discovery fails not because games are hard to find, but because trust signals do not exist.
Indie game discovery is fragmented in a specific way. More games launch every year than any player can sort through. Storefronts reward titles with existing momentum. And the signals that would help players decide, developers improve, and publishers evaluate simply never reach the people who need them.
I play a lot of indie games. I kept watching the same thing happen. A game I loved would quietly disappear, not because it was bad, but because almost no one found it. Meanwhile, projects that got attention were often just trailers. I would back something, watch a polished thirty-second clip, then wait years for a game that sometimes never shipped. That gap became the starting question: why is it so hard to tell which early games are real?
All three audiences make worse decisions because none of their signals reach each other.
The market does not only have a discovery problem. It has a signal problem. The storefront, the developer, and the publisher each see a different slice of reality. That makes traction harder to prove and good decisions harder to make.
Four decisions that shaped the system.
Each decision changed the product scope. Not toward more features, but toward a clearer structural model.
Players, developers, and publishers all had different blind spots, but those blind spots were connected. Players needed signals to evaluate. Developers needed visibility without an existing audience. Publishers needed data before commitment. The decision: design PlayFirst as a multi-sided system where a player save is visible to the publisher evaluating the same game. Signal only compounds when all three are on the same surface.
Visibility alone did not create trust. People needed signs that a game was active, improving, and worth backing. A trailer is a moment. A roadmap with completed milestones is a pattern. The decision: add roadmap tracking, milestone progress, bug reporting, and progress dashboards as first-class product surfaces. A project that updates publicly is harder to abandon quietly than one with only a launch page.
Developers often receive noise instead of actionable insight, while publishers struggle to see meaningful early traction. A comment field produces text. A structured report produces a record with severity, status, and resolution. The decision: create structured bug reporting, support signals, and overview metrics that make product health legible for everyone on the platform, not just the developer who submitted the build.
Publishers need early evidence, but that evidence only matters if it comes from actual player behavior and developer progress. Launching all three sides at once risks a ghost town: no player activity means no signal, and no signal means publishers have nothing to evaluate. The decision: sequence the product around the player and developer loop first. Developers post playable builds, players test them, and feedback becomes visible progress. The publisher layer follows once real activity makes the signal credible. Phase 1 earns trust. Phase 2 turns that trust into publisher-facing evidence.
Built for a gaming audience. Structured enough for creators and publishers.
The interface needed to feel credible for creators and publishers, while still feeling alive for a gaming audience. The dark foundation supports media-heavy content. The cyan-to-lime gradient creates a sense of momentum, progress, and early-stage growth. Color coding is functional: cyan for navigation and discovery, lime for growth and positive states, amber for review, red for critical issues.
Selected interfaces.
Players enter through a media-heavy discovery surface that makes unfinished games feel browsable and worth exploring. Before login, the page converts on trust signals alone: visible game momentum, hype scores, and funding progress without requiring an account first.
The feed helps players compare early projects through game visuals, status cues, and discovery context. Hype scores, save counts, funding progress, and community traction surface visible evidence of early momentum rather than algorithm rank.
Developers can track progress, funding, views, users, and bug reports from one dashboard. The dashboard helps developers answer whether they are ready to push for a wider release before committing resources they cannot recover.
The game detail page combines playable media, funding status, developer identity, reviews, and report actions into one trust surface. Trust compounds when all three audiences are on the same page simultaneously.
Phase 1 establishes the player and developer loop. Publishers only enter when that loop has produced real, legible signal. No manufactured metrics, no early empty dashboards. The publisher view is earned by activity, not unlocked by default.
AI as a first pass. People reveal which signals actually matter.
AI helped surface structural issues quickly across all three audience flows. Real feedback revealed which trust signals people actually used when deciding to support, report, or revisit a game.
- Reviewed IA clarity across player, creator, and publisher journeys
- Checked the upload flow for missing states and form clarity
- Evaluated dashboard hierarchy and metric readability
- Flagged status-color consistency across progress and bug states
- Identified dense areas where the system needed stronger grouping
- Users needed clearer separation between public-facing and creator-facing views
- Developers wanted more confidence about which signals mattered most
- The dashboard worked best when progress indicators were prioritized over raw volume
- The bug-reporting area needed clearer scanability and status differentiation
- Players responded better when funding and game health signals appeared together
AI helped surface structural issues, but real feedback revealed which trust signals people actually used when deciding to support, report, or revisit a game. Structural clarity is necessary but not sufficient. The emotional logic of whether a game is real cannot be tested by a heuristic review alone.
Designed, not shipped. A clearer product thesis.
PlayFirst demonstrates how a multi-sided product can turn scattered signals into a more trusted game-funding system. The strongest outcome is not a shipped metric. It is a clearer product thesis, a tighter system architecture, and a stronger model for how players, developers, and publishers can share one source of product truth.
The developer dashboard and game page share the same underlying signal layer. What a developer sees as readiness data is also what a publisher sees as early traction evidence.
The bug reporting system creates a public accountability layer. Projects that respond to reports publicly demonstrate the kind of active development that builds player trust over time.
The canonical game page means a player save, a publisher view, and a developer milestone update all happen in the same place. Signal compounds instead of fragmenting across separate surfaces.
The design work clarified where the MVP scope should begin: with developers who have a playable build and want real early testers. Players and publishers follow once that foundation exists.
Launching publishers before the player and developer loop produces useful signal would have created an empty dashboard. The sequencing decision keeps Phase 2 real: publisher interest is earned by documented player activity, not promised by platform onboarding. A funding conversation backed by actual traction data is worth more than one backed by an early access page.
The trust model needs to go deeper.
If I pushed this further, I would define the publisher dashboard more precisely. The next pass would clarify which signals are public, which are developer-facing, and which are publisher-facing only. Right now the system shows all signals to all audiences. That may be right for a first release. But as the platform matures, different audiences will need different signal hierarchies rather than the same flat view.
I would also refine how traction, sentiment, completion, funding momentum, and bug severity combine into a credible early-read system without creating misleading scores. A game with 800 saves and 40 open critical bugs tells a different story than one with 100 saves and 0 reports. The current design surfaces both numbers but does not yet synthesize them into a single health signal any audience can read at a glance. That synthesis is the next design problem worth solving, especially once the publisher layer is active and deals depend on it.