The problem with picking an end
Membership software usually chooses. Either it is cheap and handles subscriptions and fixtures, or it is professional-grade and priced beyond anyone but a well-funded organisation.
That leaves the middle unserved, and it creates a worse problem: an organisation that grows has to migrate, and migration means either abandoning its history or paying to move it badly.
We built The Performance Centre to cover the whole range — grassroots administration at £1 per player per month, academy performance analysis, and first-team recruitment with over 120 metrics per player — on one multi-tenant platform. This paper is what we learned doing it.
1. Tenancy is a data decision before it is an architecture decision
The first question is not shared-database-versus-separate-database. It is: what does one tenant need to be certain of about another?
For membership organisations holding personal data, and particularly data about children, the answer is usually absolute. A club must never see another club’s members, and that has to be true by construction rather than by every query remembering to filter.
What has worked for us:
- Tenant identity carried in the access context, not passed as a parameter that a developer can forget.
- Enforcement at the data layer, so a missing filter fails closed rather than returning everything.
- A deliberate, audited path for the rare cross-tenant case — a player moving club, a league-level report — rather than a general capability that happens to be restricted.
- Tests that assert isolation, run on every change. This is the one property where a regression is unrecoverable reputationally.
Shared schema with enforced row-level isolation is usually the right trade at this scale. Separate databases per tenant sounds safer and, in our experience, produces its own class of failure: eleven schema versions in production and migrations that succeed for some tenants and not others.
2. Branding is configuration, not a project
The commercial argument for a white-label app is straightforward. The icon on a member’s phone determines whose product the habit belongs to, and a shared platform app quietly makes your members somebody else’s audience.
The engineering argument is that this only works if branding costs nearly nothing per tenant:
- A token set per tenant — colours, logo, crest, typography — resolved at render, not baked into a build.
- Domain per tenant, with certificate issuance automated.
- App identity generated, not hand-assembled: icon, splash, store listing produced from the same tokens.
- One codebase, always. The moment a tenant gets a forked build, you have a maintenance liability that grows with your customer count.
Get this right and a club with forty players can have its own branded app. Get it wrong and only your largest customers can, which defeats the proposition.
3. Roles, not permissions
A membership platform serves people with genuinely different jobs: a coach, a player, a parent, a physio, an administrator, a recruitment lead. The common mistake is one interface with elements hidden by permission flags.
It fails because the shape of the job differs, not just the visibility. A parent needs three things and should see three things. An administrator needs a working surface. Hiding fields on an administrator’s screen does not produce a parent’s screen; it produces a confusing administrator’s screen.
Build a view per role from shared data. Six views over one dataset is more work initially and dramatically less work than the alternative, which is a support burden from people who cannot find anything.
4. Pricing shapes the architecture
At £1 per player per month, certain decisions are made for you:
- There is nowhere to hide a payments margin, so card fees are passed through at cost and the platform has to say so plainly. Clubs notice.
- Support has to be near-zero per tenant. Onboarding is self-service or it does not scale; anything requiring a call must be rare.
- Infrastructure is shared. Per-tenant infrastructure at that price point does not work arithmetically.
- Features must serve the whole range or be tiered cleanly. A feature only the top tier uses, running on shared infrastructure everyone pays for, is a slow margin leak.
The tiering itself needs care. The rule we settled on: tiers add capability, never remove data. A club moving up gains recruitment; a club moving down keeps its history and loses access to a feature. Data hostage-taking is both wrong and, in a sector where everyone talks to everyone, commercially fatal.
5. Adoption is the actual product risk
Most club software is abandoned within a season. Rarely because it is bad — because the person administering it is a volunteer with a day job, and a feature nobody has time to use is the same as no feature.
Design consequences:
- Registration has to be completable on a phone, in one sitting, by a parent who is doing something else.
- Bulk actions everywhere. Volunteers work in batches: a whole squad, a whole season.
- Nothing that requires training. If it needs a session, it will be used by the two people who attended.
- Import from a spreadsheet, because that is what exists today and telling someone to re-key 200 players ends the relationship at that moment.
6. Consent and safeguarding are structural
Youth organisations hold dates of birth, medical notes, photographs and emergency contacts, collected at speed by volunteers rather than by trained data handlers.
Build in from the start:
- Consent per permission, not one blanket agreement — photography, contact, data sharing, each recorded separately with the wording shown at the time.
- Withdrawal that takes effect everywhere immediately, which means permissions are read at point of use rather than copied into lists.
- Retention that runs on its own, keyed to an event such as leaving, not to record creation.
- Visibility by role, so the person handling subs never sees medical information.
- The parent-to-adult transition, which arrives on a schedule you can predict years ahead and is almost never built.
7. Payments, in practice
Membership billing is deceptively involved: recurring subs, joining fees, pro-rata for a mid-season start, family accounts where one payer covers three members, freezes for injury rather than cancel-and-rejoin, and failed payment recovery that does not embarrass anyone.
The last point matters more than it sounds. Chasing subscriptions is what burns out volunteer treasurers, and most of the fix is structural — automatic retries, self-service updating of card details, and the system rather than a person doing the asking.
A sequence that works
- Isolation and identity first. Everything else assumes it.
- Registration, subscriptions and consent — the administrative grind, which is what actually gets adopted.
- Per-tenant branding, before you have many tenants, while retrofitting is cheap.
- Role views, added as each role becomes real.
- Higher-tier capability last, on the same data.
Building for organisations at very different scales? Get in touch, or read about our work in sport.