Fansport tournament winning team celebrating with their trophy under the event's inflatable arch
← Back to Stories

Fansport

Digitize and unify sports tournament management, configuration, teams, refereeing, scheduling, and payments

At a glance

Vision / Challenge
Digitize and unify sports tournament management, configuration, teams, refereeing, scheduling, and payments, previously scattered across spreadsheets, chats, and error-prone manual processes.
Key Services
Product Strategy & Design · Digital Product Building
Industry
Sports Tech / Tournament management
Technologies/Platforms
Claude Code · shadcn/ui · Figma

A multi-role tournament management platform, built with Claude Code as a build partner, from domain model to working prototype, before committing to full production engineering.

A tournament has more than one user

The initial ask looked like a feature request: build a way to manage tournaments. But underneath it was a product problem. A tournament isn't run by one user, it's run by a tournament leader, team captains, referees, and a results approver, each with different goals, permissions, and moments of urgency. A financial trail has to hold up across all of them. Match results have to be reported through a shared, unambiguous code system. Scheduling has to account for venues, referee availability, and pairing rules.

Treating this as a single interface for a single client would have meant re-solving the same problems for every future organization that adopted it. The real challenge was strategic: define a product architecture that could serve multiple roles and multiple tournaments without collapsing under its own complexity.

Before any interface work started, the priority was defining the product's structural logic.

Who the actual users were, and what each one needed to decide rather than just see, shaped the decision to build four distinct role-based modules, tournament configuration, team leadership, results approval, team captaincy, instead of one dashboard with permissions bolted on. Match codes, referee pairing logic, and financial traceability per match-day weren't treated as UI details but as the product's core domain model, a strategic dependency to get right early rather than a design nicety. And rather than committing to full-scale engineering before the product logic was proven, the strategy was to build functional, role-specific prototypes first, real enough to test real workflows with real users, disposable enough to change direction cheaply.

Referee making a call during a match

A tournament leader could finally schedule a match day

This is where product strategy turned into product building. Using Claude Code as a build partner, the specified domain logic and role architecture were translated directly into working, interconnected panels, with real state, real persistence, real flows, rather than static mockups. That let the product be used, not just reviewed: a tournament leader could actually schedule a match day; a captain could actually confirm a lineup; an approver could actually see a financial trail resolve.

A shared design system was built in parallel so that as the product architecture expanded, new modules, new roles, new edge cases, it kept behaving like one coherent product rather than four disconnected tools stitched together after the fact. A full component audit later confirmed where that consistency held and where it needed to be tightened before scaling into production engineering.

One system, every future tournament

Because the underlying architecture was designed to generalize from the start, the system didn't need to be re-thought for each new tournament or organization, only configured. That's the difference between building a client feature and building a product: the strategic decisions made early (role separation, domain modeling, prototyping approach) are what let the same system extend forward instead of being rebuilt each time.

Football teams entering the field

Ready for the next tournament, and the one after that

  • A product architecture organized around real user roles instead of a single generic interface.
  • Core business logic (match codes, referee pairing, financial traceability) modeled correctly before any UI was finalized, reducing costly rework downstream.
  • A validated, multi-module prototype built and tested with real workflows before committing to full production development.
  • A reusable strategy for building future modules: domain-first specification, AI-accelerated prototyping, and a shared design system that scales with the product rather than against it.

Let's build your next triumph

Tell us about the challenge you're facing. We'll bring the team, the thinking, and the craft.

Let's Talk