Rate My PW
Founder · Product Designer · Builder · 2025–Present
A personal habit for remembering paid gaming sessions grew into a live reputation, records, and discovery product — designed, built, and shipped solo.
A small personal tool, repeatedly redefined. Each chapter starts where the previous answer stopped being enough.
Live Product is Chinese production. English Demo is a static, privacy-safe portfolio version with frozen fictional data. English screenshots below show the demo, not customer activity.
A habit I couldn’t keep in my head anymore
“PW” is short for peiwan (陪玩): a paid companion player you book to play games with you. I was a player in this market, keeping my own spreadsheet of sessions.
Market context supplied for this case study, not RMP revenue or measured outcomes. The volume figure refers to reported transactions at Dongdong Esports. Companion-gaming livestreams can draw 10K+ concurrent viewers.
Information about who was worth booking lived across livestreams, group chats, Xiaohongshu, Douyin, and private spreadsheets. My own records stopped helping me remember who I played with, which store they came from, what I paid, and how it went.
The first job was to make an experience worth remembering findable again.
I started with Reviews and Search, anchored to two entities: Player and Store. Different stores meant different prices, rules, and order types; a player’s reputation needed that context.
- PlayerHow the person played and communicated.
- StoreThe service, pricing, and after-sales context.
The next gap: remembering an opinion still didn’t explain the session itself.
How it felt vs. what actually happened
Reviews captured how the experience felt. Orders captured what actually happened.
A Review could describe a good or bad experience. It couldn’t hold the round-by-round detail: extracted value, eliminations, progress toward a target, or how a session ended. Orders became a separate, structured personal record.
More evidence, without forced publication
Orders are primarily private. A completed Order can also back a public Review through a small provenance badge, giving the opinion a traceable session context.
More detail created more work
Logging every round by hand became expensive. I introduced PaddleOCR screenshot capture to turn round results into editable fields. Optional values and manual correction remained part of the flow.
Automation should reduce work, not create more correction work.
The OCR dialog keeps the boundary visible: images stay on the device, and amounts can be reviewed before saving. Machine output is a proposal.
Richer records made retrieval a bigger product problem.
Search grew with the product
Search began with Players and Stores. As Orders and Community Posts arrived, I kept one entry point and expanded what it could connect: reputation, personal records, and community context.
Global Search spans Players, Stores, Orders, Community Posts, and Topics. Individual Reviews retain their own list search and filters.
Search became the connective layer across reputation, records, and community context.
A player name is one starting point. A game, a store, or a specific session is another. Advanced Order Search adds keyword, price, game, store, and reviewer filters when a broad query isn’t enough.
The tradeoff was more result types and more search states. The benefit was a consistent way back into a product whose information model kept growing.
A connected information system still depends on people being willing to contribute.
Lowering the barrier without lowering trust
Requiring an account adds commitment before someone can share useful information. Guest contribution lowered that barrier, while making the boundaries around public content more important.
Low commitment needed guardrails
- Existing targetsGuest Reviews can only reference existing Players or Stores.
- Public intentGuest Reviews enter Pending; they are not private account records.
- Bounded accessRate limits and bot checks constrain anonymous submissions.
Opening contribution also carries a cost: Guest Reviews lack account-based owner management, and public contributions require moderation.
The account view beside this text shows the separate member experience: Published, In Review, and Private states. It is not a Guest dashboard.
As contribution expanded, moderation developed into layered safe, defer, and reject checks, with human fallback for ambiguity. Private recording stays separate from the public-content queue.
The information should matter more than the identity of the person posting it.
Public Reviews, Orders, and Community Posts are anonymous by default. Comments deliberately show member usernames so discussion reads as a conversation. Owners can also choose a nickname in share cards.
Making contribution possible didn’t, by itself, create a reason to come back.
Discovery without becoming a forum
The record-and-search loop made a useful personal utility. During cold start, it could still feel quiet between sessions. The next question was how to add fresh reasons to return while keeping reputation information at the center.
A useful tool still needed a reason to return.
Freshness with a purpose
Community Posts—“Tea” in the demo, 吃瓜 in production—combine short-form stories, topics, optional Player or Store associations, comments, and likes. They lead back into Games, entities, and Search.
A deliberate scope tradeoff
Fresh content also introduces media, discussion, and a larger moderation workload. Return visits were the design intent; there is no measured retention result to claim.
Built for the phone next to the keyboard
Most target games are played on PC. My design premise was to make the phone a practical companion before, during, and after play. Mobile-first rules and an installable PWA made that premise tangible.
- BeforeCheck a Player’s reputation.
- DuringReference information beside the game.
- AfterRecord the session while it is fresh.
One UI contract as the surface area grew
As the product expanded, I formalized the UI rules so new features did not fragment the experience. Search and content patterns, mobile-first behavior, and shared primitives became reusable decisions.
6px controls · 8px cards · 12px elevated surfaces
Geist-inspired inputs · Lucide icons · shared Light/Dark rules
One system, two themes
Light and Dark preserve the same content hierarchy and interaction patterns. Theme support is one check that the shared rules hold together.
Designed—and built—end to end
The product decisions also live in the implementation. These two excerpts are copied directly from the product source.
A single result model connects Players, Stores, Orders, and Community Posts (GUA), alongside topics and recent items.
type HomeSearchSuggestion =
| { key: string; type: "TAG"; tag: string }
| { key: string; type: "TOPIC"; topic: GuaTopicSuggestion }
| { key: string; type: "RECENT"; item: RecentItem }
| { key: string; type: "PLAYER"; item: Player }
| { key: string; type: "STORE"; item: Store }
| { key: string; type: "ORDER"; item: DiscoverableOrder }
| { key: string; type: "GUA"; item: GuaPost };Saving requires a valid amount for every selected round and no outstanding amount-confirmation flag. Automation assists; unresolved values cannot silently become records.
const canSave =
selectedCandidates.length > 0 &&
selectedCandidates.every(
(candidate) =>
actualInputToWan(candidate.actualInput) !== null &&
!candidate.needsActualConfirmation,
);A personal tool became a connected, shipped system
I defined, designed, built, and launched the product: a mobile-first reputation and records system with Search, OCR-assisted entry, contribution controls, and Community discovery.
The Chinese production product is live. The separate English demo presents its core experience with fictional, frozen data for portfolio review.
No adoption, Guest-conversion, OCR-completion, or Search-success metrics are claimed. The evidence here is the shipped product and the decisions behind it.
Each step came from the previous answer running out of room.
Have a similar problem to work through?
wenyigu0831@gmail.com ↗