OneDex

Scan any card
Track your cards
Follow the market
Search 7,000+ cards
Complete your sets.

Inspiration

I started OneDex because collecting One Piece TCG cards quickly becomes difficult to manage once a collection grows. Prices vary a lot between printings and variants, and most existing tools either focus on competitive play or make it hard to understand what your collection is actually worth.

I wanted something closer to a portfolio app for collectors: a place where you can add the exact cards you own, see their current market value, understand how that value changes over time, and explore every printing and variant.

What I built

OneDex is an iOS app focused on collection management and portfolio tracking for One Piece TCG collectors.

Collectors can:

Search and add cards to their collection Track the total market value of their portfolio Follow historical price movements View individual card price history and analytics Distinguish between variants and different printings of the same card Browse sets and discover cards they may be missing

A key decision was to tie pricing to the specific printing, rather than only to the base card. For collectors, an alternate art, promo, reprint, or regional version can have a completely different value, so treating them as separate assets is essential.

How I built it

The app is built natively for iOS with SwiftUI, with Supabase and Postgres powering the backend.

I built a data model that separates cards from their individual printings, images, price sources, and historical price snapshots. Pricing data is ingested and normalized from external TCG data sources so that each printing can maintain its own price history.

RevenueCat handles the subscription layer and paywall, which let me focus more of the Shipathon on the product itself instead of rebuilding subscription infrastructure.

A large part of the project was built with AI-assisted development. I used coding agents heavily for implementation, debugging, database work, and iteration, while keeping the product architecture, UX, and data model decisions under my control.

Challenges

The hardest part was not building the UI. It was the data.

Trading card data is messy. A single card can exist as multiple artworks, promos, reprints, languages, finishes, and regional releases. Different APIs also identify the same printing differently, which makes matching pricing data to the correct card surprisingly difficult.

Building a reliable mapping between the card catalog and pricing providers became one of the biggest technical challenges of the project.

Another challenge was keeping the app simple despite the amount of underlying data. Collectors need depth, but they should not have to understand the complexity of the database to add a card or check its value.

What I learned

The biggest lesson was how important data architecture is for a product like this. Modeling cards and printings correctly early on makes almost every future feature easier, from pricing to portfolio analytics and collection completion.

I also learned how much faster a solo builder can move with modern tools. Using SwiftUI, Supabase, RevenueCat, and AI coding agents made it possible to build something that would previously have required a much larger team.

Most importantly, I learned to keep the scope centered around one question:

Can a collector open OneDex and immediately understand what they own and what it is worth?

That has guided most of the product decisions so far.