Sports Governing Body Software Problems: The 5 That Cost You Money and Risk, and How to Avoid Them

Why does eligibility get scoped as a status field so often?

Because on a requirements document, member is eligible reads like an attribute of a person, and every developer alive has built a users table with a status column. It is a familiar shape and it is the wrong one.

Eligibility in a national or regional body is a conjunction of records you do not own, each on its own clock. Membership paid for the season. A background check from your approved vendor, usually on a two year cycle. Safeguarding education, which under the federal SafeSport framework in the United States means a core course plus an annual refresher, and in the United Kingdom means a Disclosure and Barring Service check plus a recognised course. Concussion education in many sports. A signed code of conduct for this season. A coaching licence at the right level for the age group. For athletes, medical clearance, age verification and often a classification record. Store the conjunction as one boolean and you have taken a photograph of something that keeps moving.

There are two tells worth checking before you accept a proposal. Ask whether eligibility is evaluated live at the moment of use or written by a nightly batch, because batch is exactly how a Friday midnight expiry survives until Saturday afternoon. Then ask what the system tells a club secretary when someone fails. Ineligible is useless. Safeguarding refresher expired on 14 March, renew here, is something a volunteer can act on before the coach turns up. A third check: ask the developer whether a person can hold several roles at once, athlete in one discipline and official in another. If that question surprises them, the schema will not survive your second sport.

What goes wrong when you migrate member and club history?

Legacy membership data is not a clean list of people. It is twenty years of clubs creating records for the same human being under a maiden name, a nickname, a misspelling and a second email address, and nobody has ever had a reason to reconcile them. Import it as it stands and your new system starts with a duplicate problem it did not create and will be blamed for.

The dangerous operation is the merge that combines two different people, because it is quiet and it corrupts service history in both directions. Treat merges as reversible events with full history rather than as destructive updates, decide before you start who is allowed to approve one, and run reconciliation reports per club so the people who created the duplicates are the people who resolve them.

Migrate at least three prior seasons. Continuous service records matter for coach licensing, official grading and long service recognition, and they are the evidence base if a historic safeguarding question is ever raised. The second trap is the expiry dates themselves, which in most legacy systems were typed by hand from certificates that no longer exist. Do not import an eligible flag from the old system. Recompute eligibility from the credential records, and expect that recomputation to show that a meaningful slice of your membership was never eligible under your own written rules. That is a finding rather than a defect, and it is far better discovered during migration than by a journalist.

Why do screening and education provider integrations break after launch?

Because a background check is a lifecycle and most integrations are built as a status pull. The real states are ordered, applicant invited, applicant completed consent, vendor processing, result returned, adjudication required, cleared or not cleared. Providers such as the National Center for Safety Initiatives and Sterling Volunteers all expose that sequence, and the single largest source of ineligible coaches on a Saturday is a person who never finished the consent form in June and has sat in one state ever since.

The failure after launch is silent rather than loud. A callback stops arriving after a vendor changes something on their side, and your system keeps displaying processing indefinitely. Processing does not look like an error, so nobody investigates, and your operations team believes checks are in flight that were never started. The fix is to treat absence of movement as an alert in its own right, with an age threshold per state, and to reconcile counts with the vendor monthly rather than assuming agreement.

Education providers break differently. The core course and the annual refresher are separate completions, and a feed that maps both onto one completed field will quietly mark refreshers as satisfied by the original course. Reconcile those counts too. The third integration is payment, and if clubs collect on your behalf or regions take a share of the fee, that is split settlement rather than a checkout, which is a different piece of work with different failure modes. Ask any developer to name the specific screening vendor, education platform, payment processor and results or timing system they have integrated. Four names, not a category.

What happens when adjudication and event day check in are not covered?

A returned screening record is rarely automatically disqualifying. Most bodies run a review panel against a rules matrix by offence type and recency, with an appeal path. If your software holds only a cleared or not cleared flag and a document store, that process is happening in email, and the audit trail that will be examined if anything goes wrong does not exist.

Adjudication needs restricted visibility built into the structure rather than into a role an administrator can change. A club secretary sees cleared or not cleared and never the underlying record. The national safeguarding lead sees the detail. Every access is logged permanently, which protects your staff as much as the applicant, because when a disclosure leaks under a role based model there is no evidence in either direction.

The other uncovered gap is the check in table itself. Sports halls do not have signal. A screen that spins is a screen that gets bypassed by a volunteer with forty athletes queueing, so the offline behaviour is a design decision rather than a detail: a local snapshot synced before the event, a visible staleness indicator so the volunteer knows how old it is, and scanning rather than typing so a transposed digit does not pass the wrong person. Two related gaps ride alongside it. Officials assigned to a sanctioned event must be re-evaluated shortly before the event date and not only at assignment, because certifications lapse in the gap. And club affiliation is an annual renewal with its own requirements, so a club that has not renewed cannot have eligible members and the system should say so in August rather than at the first fixture.

Should you build custom or configure what you already own?

If you are a single discipline body under roughly 5,000 members, you do not sanction events with insurance implications, and your safeguarding requirement is one course with one expiry, buy. Sport80 and JustGo are built for governing bodies rather than clubs, they cost far less than a build, and they will serve you properly. If what you actually operate is a league rather than a sanctioning body, SportsEngine is the right answer and a custom build would be an expensive way to arrive at the same place.

Be clear about where those products stop. They hold membership as a national record and they do it well. They were not designed to express a conditional rule set that varies by role, age, discipline and level, to run a permissioned adjudication workflow with an appeal path, to treat clubs as sub tenants with their own affiliation requirements gating member eligibility, or to tie an event sanction to a live eligibility evaluation. Those are the gaps where governing bodies reach for spreadsheets.

Build when two or more of those are true, or when you run several disciplines whose rules are genuinely different rather than variations of one another. The threshold is not member count. It is whether your rules fit in a configuration screen, and if a vendor has ever told you a requirement needs a workaround, you already have your answer.

How do hidden costs get into the quote?

Discipline count is the largest multiplier and the one most often absent. Each discipline usually brings its own categories, licences, age bandings and eligibility rules, and they are not settings. If the proposal does not name the disciplines in scope, it is priced for one.

Ranking and results feeds are the second. A national ranking is real logic with real disputes attached, and it must be reproducible historically under the algorithm that applied at the time, which is a different and more expensive thing than a leaderboard. Third, payment complexity: if clubs collect on your behalf or regions take a share, that is split settlement and it belongs in the quote as its own line. Fourth, offline check in, which is genuine engineering rather than a mobile view. Fifth, multi season migration, where the identity resolution work concentrates.

Sixth, and never in any developer's number, your own people. Someone in your office has to decide which requirements apply to which role at which level, and your safeguarding lead has to sign off the adjudication matrix. Bodies that attempt to redesign eligibility policy and build software in the same quarter run late on both. Write the rules down first, then build to them.

What separates a build that works from one that fails here?

Sequence decides it. The builds that work start with the person record, credentials with issuer and expiry, and eligibility as a computed view, then add club affiliation, then sanctioning and officials. The ones that fail start with the member facing portal because it is the visible part, and end up with an attractive renewal journey feeding an eligibility model that is still a spreadsheet in the national office.

Put a volunteer in the review sessions from the first week. The people who decide whether this software works are standing at a trestle table in a sports hall with a queue in front of them and no signal, and their tolerance for a slow screen is zero. Requirements gathered only from the compliance office produce systems that are correct and unusable.

Insist that eligibility is evaluated live and that every refusal names the failing requirement and its date. Insist that merges are reversible. Then settle ownership in writing before kickoff: the repository, the cloud accounts, unrestricted exports of member data, and the right to bring in another firm. At Digital Heroes the governing body owns the code from the first commit. Settle data residency and retention at the same time, because with safeguarding records in the system those are far harder to renegotiate once you hold several seasons of history.