- A web platform where each card has one shared record and collectors can mark that they are looking for it or have it available.
- Live Beta
- Pokémon TCG collectors in Türkiye.
Context
Card trading often happens across comments, group chats and direct messages. The same card is described repeatedly, while availability, condition and intent are recorded in different ways. Poketopu brings those conversations onto a shared catalogue.
My role
I defined the product structure, matching model and user flows, designed the interface and built the working web platform.
What I made
A searchable card catalogue, looking-for and available lists, a five-step condition scale, image uploads, collector profiles and direct contact between matching users.
How matching works
- Every card has one shared catalogue page.
- Collectors add themselves to the looking-for or available list and record the card's condition.
- When the two lists intersect, the collectors can contact each other directly.
Key decisions
- Condition is required because the same card may have very different trade value depending on its physical state.
- Payment and delivery remain between the two collectors.
- The platform helps people find each other; it does not act as a shop, auction or valuation service.
The interface
The live interface keeps the catalogue, filters and listing actions visible without turning the card page into a dense marketplace screen.
Current status
Poketopu is open at poketopu.com as a free public beta. The catalogue and the core matching flow are live. The next phase is expanding catalogue coverage and refining search and filters.
Built with
Next.js 16, TypeScript, Supabase and PostgreSQL.
What changed in my approach
The shared catalogue became the central product decision. Once the card record was treated as common infrastructure, listings and matching became much simpler to organise.