Digital card catalog empowers collectors with frictionless online deck building

PROJECT OVERVIEW

ABOUT THE CLIENT

This case study is based on a real VNEXT project. The client's identity and certain project details have been anonymized or generalized for confidentiality purposes.

Our client serves a community of trading card game players and collectors in Japan, and wanted an online home where those players could search for cards, assemble decks, and share their creations with other players. Exact financials are withheld for confidentiality.

THE CHALLENGE

The platform's frontend depended on an API being built at the same time by a separate team outside VNEXT, which meant requirement clarity and schedule visibility mattered as much as the code itself. Changes made on the API side needed to reach VNEXT quickly enough to keep test cases and frontend work aligned with what the API actually delivered.

Requirements themselves started at a high level, general direction for the UI and the deck building experience, rather than a fully detailed specification, which meant translating customer intent into a concrete design document was part of the work itself.

PROJECT OBJECTIVE

The client wanted a web platform where players could search an existing card catalog, build and organize their own decks, and share those decks with the wider player community, delivered in step with a companion API being developed independently.

APPROACH AND METHODOLOGY

Turning high level direction into a concrete design

Rather than wait for a fully detailed specification, the team worked directly from the customer's high level requirements, then built out UI design and design documentation collaboratively, confirming direction with the customer as details were clarified rather than after the fact.

Keeping two independent teams moving together

With the API developed by a separate company, VNEXT's bridge engineer took responsibility for making sure both the customer and the API team communicated changes to VNEXT as they happened, so test cases and frontend logic could be updated in step with the API rather than falling behind it. A shared Slack channel connected VNEXT, the API team, and the customer directly, backed by a weekly video call to review progress and open questions.

Setting shared working rules across every team on the project

As more teams became involved, VNEXT's project management defined working processes that applied consistently across all of them, and kept daily pressure on cross team commitments so a slower response from any one side surfaced early rather than becoming a bottleneck near a deadline.

TEAM SCALE

VNEXT staffed this engagement with a small, senior team working directly alongside the customer and the separate API team.

• Dev Lead: shaped the frontend architecture and user experience, contributed reusable frameworks and components, and reviewed the team's work for both performance and frontend security
• QC Lead: owned test quality and delivery timelines, kept testing checklists current, and raised process improvements as the project evolved
• Developers and testers: built the deck search and sharing experience and verified it against requirements clarified directly with the customer

THE SOLUTION AND TECHNOLOGY STACK

The finished platform gives players a single place to find cards, build decks, and share them, all connected to a card catalog maintained through the companion API.

What was built

• Deck search: lets players search and filter an existing card catalog to find cards for their decks
• Deck building: lets players assemble and organize their own decks from the cards they find
• Deck sharing: lets players publish decks for other users in the community to browse and reference

The frontend was built to consume data from a companion API developed independently, keeping the two systems in sync as both evolved throughout the engagement.

Technology Stack

THE RESULTS

Players now have a single place to search, build, and share decks, built to stay in step with an API that was still taking shape at the same time.

• A functioning deck platform delivered alongside a moving target: the frontend stayed aligned with a companion API developed independently and still evolving throughout the engagement
• Fewer dropped changes across teams: a direct communication channel between VNEXT, the API team, and the customer meant API level changes reached test cases and frontend logic promptly rather than surfacing as bugs later
• One set of working rules across every team involved: shared processes applied consistently across VNEXT and the API team kept the wider project moving as a single coordinated effort rather than several disconnected ones

For a platform whose value depends entirely on how easily players can find and share what they are looking for, a search and deck building experience built in step with its own data source, rather than ahead of or behind it, is what makes the platform genuinely usable from launch.