WinZone: Building a Full Fantasy Sports Platform, Not Just a Website

WinZone is a fantasy sports and gaming platform — not a single website, but two connected systems that had to work together. On one side, the user-facing app: contest creation, leaderboards, a wallet system, and the actual gameplay experience users interact with. On the other, a full admin panel for running the platform day to day — user management, payments, compliance, reporting, support. Both sides had to be built, and both had to be solid, because a fantasy sports platform that's polished for users but unmanageable behind the scenes doesn't survive contact with real operations.

It's built as a Next.js monorepo using Turbopo and pnpm workspaces, with Supabase as the backend, and a light 'Golden Trust' theme across both the user and admin surfaces. The monorepo structure mattered here specifically because the user app and admin panel share code — types, Supabase queries, UI primitives — but need to ship, scale, and evolve somewhat independently.

The user-facing side is what most people would call 'the product' — where contests get created, where leaderboards update, where the wallet handles deposits and winnings. That's the part that has to feel fast and trustworthy, because it's the part people are actually spending money and time inside.

The admin panel is where I learned the most, mostly because I got it wrong the first time. Early on, it was a pile of routes that grew one at a time, whenever I needed to check something or fix a user's balance manually. It worked for me, alone, at 2am. It would not have worked for a support team, a finance person, and a compliance person all using it at once — which is what actually running a gaming platform requires.

So I reorganized the admin panel into seven route groups using Next.js's `()` route group syntax — user management, contests, payments, compliance, reports, settings, and support, each isolated with its own layout and permissions boundary. Alongside that, I consolidated 20 separate SQL migration files — several no longer idempotent, meaning re-running them on a fresh database could fail or produce inconsistent state — into a single, clean, idempotent schema file. Neither change is visible to an end user. Both were necessary before I could trust the platform enough to hand any part of it to someone other than myself.

From there, I started specifying a much larger admin system — a 14-category enterprise admin panel spec covering roughly 90 features, everything from granular RBAC to audit logs to dispute resolution workflows. For modules in that spec that exist on paper but aren't built yet, I use a `ScaffoldNotice` component — an honest placeholder that says 'this is planned, not live' — rather than a broken link or a page that silently does nothing.

The lesson that stuck: building the part users see is maybe half the work on a platform like this. The other half — the tools to actually operate it safely, at scale, with more than one person touching it — is just as real a piece of engineering, even though nobody using the app ever sees it directly.