← All writing
Club software · November 2026
The Club Platform I Keep Sketching
No club management platform is perfect, and I doubt one ever will be. Youth clubs vary too much for that. A 200-player community club, a 2,000-player multi-region competitive club and a volleyball club that runs like a retail business with courts to fill all need different things, and every club has its own history, habits and quirks.
Still, after living deep in the weeds of club operations, working in the software space for years, and being the person who pushes the tools hardest, I’ve come to believe some components would make a genuinely stable foundation.
One caveat up front: what I would have proposed a year or two ago looks very different from what I’d propose today. AI has changed what’s possible faster than anything I’ve seen in software. So treat the diagram and ideas here as a snapshot. They’ll change as the technology improves, as I learn what works and what doesn’t, and as the market’s demands shift. But I think it’s a good start.
Where this comes from
I came to youth club operations from software, after years in marketing operations at SaaS companies and a decade coaching high school soccer on the side. When I joined a large competitive club, I found what most clubs live with: a registration platform at the center and a patchwork of spreadsheets, forms, and side tools around it.
Every time staff needed something the platform couldn’t do, we built around it. A nightly data pipeline to get our own data out. A mapping file to match league team names to our team names. Dashboards for registration pacing, retention, and revenue. A coach game-report form. A private training booking app. Dozens of small AI automations that do the clicking for us, from updating game uniforms to setting up payment plans.
At some point I realized that collection of workarounds was a spec. Each one marks a place where clubs need something the software doesn’t give them. Line them up and a picture of the platform clubs actually need starts to emerge.
The problem is foundations, not features
When I sorted the workarounds by why they exist, the same few root causes kept showing up. Very few were about a missing feature. Most were about the foundation underneath.
- The data is locked in. Clubs can see their data in the app but often can’t get it out, automate it, or connect it to anything else.
- Nothing shares an identity. A team has one name in the league system and another in the club’s. A coach has a different record in every tool. Mapping spreadsheets end up as the glue.
- The club’s own structure isn’t built in. Region, program, and cohort live inside team names instead of as real fields, so every report has to rebuild them.
- History gets overwritten. Move a player to a new roster and the original registration date can disappear. Closed seasons get archived by hand.
- Bulk work happens one click at a time. Anything that touches hundreds of games or packages becomes an afternoon of clicking.
- Staff operations live elsewhere. Practice schedules, shifts, payroll, and private training each sit in a different place.
- Growth has no home. Leads, town partnerships, alumni, and the questions families ask all live outside the system that runs the club.
Fix those, and a lot of features become easy. Leave them, and every new feature becomes another island.
The foundation: an open club data core
The heart of the platform I keep sketching is a data core that models a club the way a club actually works, and stays open to everything around it.
It starts with people, because clubs are people businesses:
- Household is the account: billing, address, hometown. It plays the role a company plays in business software.
- Guardians are the contacts who get messages and make payments. A household can have more than one.
- Players are often minors without their own email. A player can be on several teams at once (a club team, a training group, a guest spot) and carries a full history across seasons.
- Coaches have one staff record and one ID that every tool recognizes.
Then the club’s structure: teams linked to the names leagues use for them, programs with real categories, regions and pricing, and seasons that are kept as a snapshot when they close.
Two ideas make this work. First, one person can hold many roles. A parent might also coach or volunteer, and a player might grow into an alumni or a staff member. One record with many roles prevents the duplicates that make club data so messy. Second, the core is open by default, with an API, webhooks, Zapier support, and an MCP server so AI tools can work with it directly. A club’s data should be as easy to use as it is to collect.
Scott Brinker makes this case well in The SaaS moats are crumbling, but the opportunity is bigger. He argues that features, interfaces, and data lock-in are all weaker defenses than they used to be:
This doesn’t mean data is irrelevant. But data alone is a weak moat when every application in the stack is reading from and writing to the same cloud data layer. If your primary value proposition is “we hold your data,” you’re in trouble, because your customers’ data teams are already busy consolidating that data somewhere you don’t control.
That rings true for club software. A platform that keeps a club’s data behind manual exports isn’t protecting much. It just pushes the club to build pipelines around it, which is exactly what I ended up doing. Brinker sees the bigger opportunity in context: the domain knowledge, rules, and operating logic that let people and AI agents act well. For a club platform, that means understanding how a club actually runs, from registration windows and tryout timing to how a player moves up a pathway. That’s worth building on, and it becomes more valuable the more open the data around it is.
What sits on top
The diagram reads top to bottom. Families, coaches and staff work through an AI operations layer. Below that sit the modules, and every module reads from and writes to the same data core. The core stays open to the systems around it: league platforms, staffing and payroll tools, a CRM, and AI tools.
The modules fall into a few groups:
- Running the season: programs and registration, subscription programs, schedules and games, events and camps, and facilities.
- Supporting staff and coaches: staff operations, coach game reports, coach development, and bookable services like private training.
- Developing players and keeping families: player development, team health, and family help.
- Growing the club: growth and CRM, the marketing website, and reporting across all of it.
None of these is exotic. What changes is that they share one foundation instead of each keeping its own copy of the truth. A program’s website page builds itself from the program record. A team health score draws on attendance, family feedback, and coach game reports without anyone exporting a file. A retention report can tell a player who left from a player who moved up to a higher team.
What AI changed
Two years ago, my version of this would have been a long list of features and integrations, mostly about getting data out of one place and into another. AI has shifted where the value sits.
The interface is becoming a conversation. In most tools I use now, the fastest way to get something done is to describe it. One morning I asked an AI assistant to pull data from our database and our CRM, combine it into a sheet our directors could use, and log the result in our project management tool, all in one chat. Club staff will expect the same from their club platform: “Create a futsal program for these dates, ages and prices,” and it happens. Families will expect the same as well: “When and where is Julie’s game on Sunday, oh, and what uniform do we need to pack?”
Bulk work becomes a saved recipe. The clicking that eats staff afternoons, like updating uniforms across 200 games or applying new payment plans to 40 packages, can be described once and run again whenever it’s needed.
The data core matters more, not less. AI is only as good as the context it can reach. A platform with clean, linked, open data gives an assistant something to work with. A closed one leaves the club copying and pasting.
The question is whether to build the assistant in or open the doors. I think the answer is both: an assistant inside the product, tuned to how clubs work, for most staff, and open connections like MCP for clubs that already run their work through their own AI tools.
One system or two? Thinking out loud
One question I keep going back and forth on: where should a family’s relationship with the club live before they register?
Today at some clubs, a CRM is the system of record while a family is just interested: they fill out an inquiry form, get follow-up emails, maybe talk with a director. Once they register for a tryout or a program, the club management platform takes over. The handoff between the two is usually manual, one-way or overnight, so nobody has the full picture of a family from first click to fifth season.
There’s a real case for putting it all in one system. One record from first inquiry to alumni. Lead source, conversion, retention, and lifetime value in a single report. Nothing to reconcile, and one place for staff to look.
There’s also a real case for keeping a dedicated CRM. Marketing automation, email and lead scoring are hard to do well, and club platforms tend to treat them as an afterthought.
Where I’ve landed for now is to split it by job, not by stage. The data core should own identity from the very first touch: an inquiry creates the household and player record, with a stable ID and a lifecycle stage, before anyone registers. The CRM, built in or connected, owns engagement: sequences, scoring and campaigns. And the two should stay in sync through events as they happen (registered, assigned to a team, missed a payment, didn’t return) rather than through a file at 2 a.m. Two systems were never the real problem. The real problem was two identities and a slow, one-way handoff between them.
Principles that matter more than features
These come from lessons learned building tools and I think should shape every module:
- Keep things simple for families and handle the complexity behind the scenes. Parents should book, register, and pay in a few steps. The hard parts belong on the admin side.
- Meet staff where they are. Lots of club coaches are part-time and use personal email. Many directors aren’t technical. Tools have to work for all of them.
- Show the math. Every number on a dashboard should open to the records behind it. People trust what they can check.
- Never surprise people. Automations shouldn’t overwrite what someone entered by hand or message families without a person deciding to.
- Flag, don’t guess. When data doesn’t match, surface it for a person to resolve instead of quietly picking an answer.
- Keep the history. Original registration dates, closed seasons, and past rosters are what make retention and development tracking possible.
- Adoption is the hard part. A system only one person uses has failed, however good it is. Getting the tools right is easier than getting people to change how they work.
A starting point
I fully expect parts of this to look naive in a year, as AI keeps moving, as I learn which ideas hold up, and as clubs and the market ask for things none of us can see yet.
What I’m more confident about is the direction: club software should treat a club’s data as the club’s, model the club the way it actually runs, stay open to the tools around it, and take busywork off staff so they can spend their time on players and families.
If you run a club, build software for clubs or just think about this stuff, I’d love to compare notes.
← All writing