Fullcourt Training

FULLCOURT TRAINING is a project that spans both a Next.js website and an Expo mobile app, both connected to the same Supabase backend. The project allows users to create accounts, save drills and plays, and purchase a monthly premium subscription, which grants access to even more drills and plays across both platforms. This is made possible by RevenueCat.

What is Fullcourt Training?

Fullcourt Training is a digital basketball platform I built to make drills and plays easier for basketball coaches and players to access, understand, and use in practice.

It combines a web experience and a mobile experience around the same product idea: animated basketball drills and plays that are easy to browse, filter, and save. I also built it around a hybrid content model, where some drills are public and freely available, while premium content is unlocked through a subscription.

What made the project especially interesting was that it was not just a content website. I had to think about authentication, profiles, bookmarks, premium access, and cross-platform subscriptions as parts of one coherent product. On top of that, Fullcourt Training was built as a basketball-specific extension of the Onside – Training concept, with the long-term ambition of creating a foundation that could later be adapted to other sports.

The Problem

I did not start this project by picking a tech stack and then looking for a problem to solve. I started with a product problem.

Onside – Training, a previous client of mine, already had experience distributing animated sports content digitally, but their existing setup had some clear limitations. It was difficult for them to experiment with a subscription-based premium model, and their native app efforts were detached from the web solution. That made synchronization between purchases and user access messy across platforms.

To understand the real problem better, I gathered requirements through informal semi-structured interviews. I spoke with the Onside – Training team and with a pilot basketball coach user. This gave me both a business perspective and an end-user perspective early in the process.

The interview with the Onside – Training team focused on their current digital solution, what was working, what was not, and what they wanted from a future platform. Their priorities were not tied to a specific framework or CMS. Instead, they cared about being able to test a subscription-based monetization model, having a native mobile app, and making sure payments and access were synchronized throughout the solution.

The interview with the pilot basketball coach gave me domain insight into how the actual end user thinks. He wanted a digital basketball playbook that was always available, easy to navigate, and intuitive to use during training planning. Search and filtering needed to be simple but powerful, and the content had to be clear enough that both coaches and players could understand it quickly.

That requirement work shaped the rest of the project. Rather than guessing what the system should do, I translated interview notes into explicit requirements and then into technical research questions. In simple terms, the process looked like this:

Interviews → Requirements → Research Questions

That helped me keep the project grounded in real needs instead of abstract technical preferences.

Product Requirements

From the interviews, a few clear product requirements emerged.

First, the solution needed to support digital content across both web and mobile. I could not treat the website and app as completely separate products if the experience was supposed to feel unified.

Second, the platform needed to support subscription-based monetization of premium content. This was one of the core business goals behind the project. At the same time, purchases made in one part of the system had to be reliably available everywhere else.

Third, the solution needed to function as a true digital basketball playbook. That meant I needed a structured content model for drills and plays, including categories, types, player counts, and filtering options. The content could not just be stored as generic blog posts or media entries.

Fourth, the platform needed to be easy to use for non-technical users. Both the stakeholders and the pilot coach made it clear that the product had to feel intuitive and require little to no onboarding.

Finally, the solution needed to align with the Onside – Training identity while still being adapted to basketball as its own sport. So part of the challenge was preserving a recognizable design language and structural logic, while still building something specific to basketball coaches and players.

These requirements became part of the foundation for the technical design.

Key Technical Decisions and the Stack

Once I had the requirements in place, I could make technical decisions based on what the product actually needed.

One of the biggest decisions I made was to treat the platform as a cross-platform product from the beginning. Instead of thinking of the website and the mobile app as separate systems, I treated them as two clients built around the same core domain. That meant user identity, content access, and subscription entitlements needed to behave consistently everywhere.

I also made a conscious decision to design around the product model rather than around individual pages or platform-specific features. The most important things in the system were not routes or screens, but the core entities: drills, plays, users, bookmarks, and subscription entitlements. That made the architecture easier to reason about and better aligned with the long-term goal of duplicating the concept for other sports later.

The technical stack needed to support a modern web experience, a native mobile experience, authentication, profile data, content access rules, and cross-platform subscription handling without becoming overly complicated. I wanted a setup that was fast to build with, maintainable over time, and flexible enough to support future growth.

Another important decision was to keep the solution understandable. Since the stakeholders were primarily non-technical, there was little value in building something overly abstract or complex. The stack had to support speed, clarity, and business flexibility, not technical cleverness for its own sake.

Public and Premium Drills

One of the central product decisions in Fullcourt Training was the split between public and premium drills.

I wanted the platform to provide real value even before someone subscribed. Public drills let visitors explore the product, understand the quality of the content, and get a feel for the platform before committing. At the same time, premium drills created a clear reason to subscribe.

This sounds simple, but it shaped a lot of the implementation. I was not just hiding content behind a paywall. I had to design a content and access model that worked for anonymous visitors, free registered users, and paying subscribers without making the experience feel fragmented.

That meant each drill or play needed a clear visibility state, and the interface had to communicate access levels in a way that felt natural. The challenge was finding the balance between discoverability and monetization. If too much content were locked away, the product would feel closed off and hard to evaluate. If too much were free, the premium offering would lose some of its value.

So the public-versus-premium split became both a product design decision and a technical architecture concern. It influenced how content was modeled, how access rules were enforced, and how users moved through the product.

Auth, Profiles, and Bookmarks

Authentication was a core part of the platform because Fullcourt Training needed to do more than just display content. It needed to recognize users, remember what mattered to them, and connect them to their saved content and premium access.

That is where profiles and bookmarks came in. Bookmarks were especially important because they made the platform more useful in practice. A coach or player could save drills and come back to them later instead of searching from scratch every time. That small feature changed the product from being just a content library into something more practical and personal.

Profiles also mattered beyond personalization. They became the link between the user and the rest of the system, including saved drills and subscription entitlements. Without that identity layer, I would not have had a reliable way to connect a user’s actions across the web and mobile parts of the product.

From a product perspective, this also helped create a smoother path from free use to premium use. Even before subscribing, a user could create an account, interact with the platform, and build habits around it. That made the upgrade path feel more natural.

At the same time, I had to think carefully about handling user data responsibly. The identity model needed to be simple, secure, and closely tied to the access model without exposing payment logic more than necessary.

Syncing Subscriptions Across Web and Mobile

The hardest technical problem in the project was making subscriptions work across both web and mobile.

From the user’s perspective, this should feel completely obvious. If someone signs up on the web and later subscribes through the mobile app, they expect premium access everywhere. If someone starts in the app and then logs into the website, they expect the same thing. The product should not care where the purchase happened.

From a system perspective, though, this is much more complicated. Different platforms have different purchase flows, different account assumptions, and different ways of restoring purchases. That meant I could not think only in terms of payments. I had to think in terms of entitlements.

The real question was not just whether a payment had happened. The real question was whether a given authenticated user currently had premium access and whether the product should unlock premium content right now.

That changed the way I thought about the architecture. Subscription logic could not live as an isolated billing feature. It had to be tightly connected to user identity and access control. I needed a model where entitlement state could be reflected consistently across both the website and the mobile app, even in edge cases like restored purchases, delayed updates, or account mismatches.

This ended up being one of the strongest arguments for treating the project as one system instead of as a website plus an app. If subscription access is fragmented, the whole experience breaks down. If entitlement logic is unified, the product feels coherent regardless of platform.

Biggest Challenges During Development

One of the biggest challenges during development was translating product expectations into technical structure without overengineering the solution. The stakeholders were very clear about what they wanted from the product, but they were not concerned with implementation details. That meant I had to interpret their expectations and turn them into a technical design that was flexible, maintainable, and realistic to build.

Another major challenge was content modeling. Drills and plays are not just generic content entries. They have categories, player counts, types, and visual structure that matter a lot in actual use. I needed a content model that supported this structure in a way that matched how coaches think when they are planning training sessions.

Cross-platform consistency was another major challenge. It is one thing to build a web product and another to build a mobile app, but it is much harder to make both feel like parts of the same system. Features like bookmarks, authentication, and premium access become more complicated the moment they need to behave consistently across different clients and purchase flows.

I also had to balance flexibility with clarity. The platform needed enough structure to support advanced filtering and future growth, but it also had to remain intuitive for users with no technical background. In other words, I had to avoid building technical flexibility at the expense of product simplicity.

Mistakes and Takeaways

One of the biggest takeaways from the project is that product requirements need to come before technical preferences. It would have been easy to start by comparing frameworks, CMS options, or architectural styles, but that would have missed the point. The most important questions were about subscriptions, cross-platform access, content structure, and usability.

Another takeaway is that subscription synchronization is not a minor implementation detail. It is a core domain problem. If I had treated it like something that could be added later, I probably would have ended up with a fragmented and frustrating product experience.

I also learned that content structure matters just as much as interface design. A platform like Fullcourt Training does not succeed only because it looks good. It succeeds because drills and plays are organized in a way that makes sense to the people using them. Filtering, categories, and visual clarity all have a direct impact on whether the product is actually useful.

One recurring mistake was underestimating how much iteration product details need. Features like filtering, access control, and saved content can seem straightforward at first, but they become much more nuanced when they meet real user behavior and real business rules.

Overall, the biggest lesson I took from building Fullcourt Training is that a cross-platform content product only works when content, identity, and access are designed as one system. That was the central challenge of the project, and it was also the most valuable thing I learned from it.