← All work 01 · Two-sided marketplace · B2B + B2C

PlayTest ID

A two-sided marketplace for Google Play developers and paid testers.

10 missions · 120 testers · 2 paid plans

Role Project Manager · Business model · Frontend & Backend Team 4 people including me Period April — June 2026
Repository ↗
Laravel Filament Tailwind Kotlin MySQL
PlayTest ID — Two-sided marketplace · B2B + B2C
Two paid plans with a feature breakdown
Two paid plans with a feature breakdown
How the platform works in three steps
How the platform works in three steps
Benefits for developers and testers
Benefits for developers and testers
Tester panel on mobile
Tester panel on mobile
Mission status and testing evidence
Mission status and testing evidence
10 Missions published
120 Registered testers
2 Paid plans
3 Role panels
Role
Project Manager
Team
4 people
Duration
3 months
Type
Two-sided commercial product

Context & problem

Google Play requires new apps to be tested by real users for 14 days. Small developers find it hard to recruit testers and track the proof. On the other side, many users want to earn extra income from their phones.

Role & responsibilities

I owned scope, priorities, and the business model — two plans, payment flow, payout flow — while building both frontend and backend. Three others covered Android, interface, and data plus reporting.

Planning

Four parallel tracks with their own definition of done: identity, missions, money, and device tracking. The money track went first because it carried the most risk; weekly timeline with one milestone per week.

Coordination

A short sync at the start of the week, a mid-week check-in to clear blockers. One shared set of board statuses, and every scope-changing decision recorded in one place.

Progress monitoring

I tracked proof, not percent complete: can a developer publish a mission, can a tester submit evidence, do payments and payouts succeed. The weekly summary set the next priorities.

Risks & responses

Risk Payment gateway and payout integration taking longer than estimated.
Response Prioritised first and tested with small transactions before adding other features.
Risk Testers not actually opening the app daily, breaking the 14-day requirement.
Response Automatic usage tracking from the device instead of manual screenshots.
Risk Scope creep from three user roles with different needs.
Response Three panels separated from the start with clear permissions per role.

Outcomes

  • 10 testing missions published and 120 testers registered in the system.
  • Two paid plans (Regular and Pro) running with payment and payout flows.
  • Test results summarised automatically by AI Report, reducing manual work for developers.
  • Judged the strongest project outcome by the course lecturer, and became the basis for a 2026 PKM submission.

What I would do differently

What I would do differently: define done for the money flow more strictly from the start, and write down pricing assumptions earlier so technical decisions are not blocked by business ones. I would also add a simple load test before the demo, because several issues only appeared when many accounts were used at once.

Artifacts

Documentation reconstructed from project archives for portfolio purposes.