Nothing happens at first. Custom software keeps running when its developer disappears, and it goes on running until something around it changes: a bill goes unpaid, a certificate or domain expires, or the club needs a change that nobody can make. The risk is a slow loss of control, not a sudden stop, and a club can protect itself by holding a few things in its own name.
What goes wrong, and when
- The hosting bill. If the server is paid from the developer's card, it runs until their payments stop. Then the registration site goes offline, possibly in the week sign-ups open.
- The domain name. If it lapses, the website goes with it, and the club's email too if it uses the same domain.
- Security certificates. These expire on a schedule. Renewal can be automatic, but when it fails, browsers show parents a warning page.
- Outside services. The payment processor, the email sender or the text message service changes something, and the software needs a small update to keep working with it.
- Change. A new age group, a new fee structure, a league rule on registration data. The software is fine, and nobody can alter it.
What the club should hold itself
Clubs are run by volunteers and committees turn over, so the rule is that everything belongs to the club, not to a person.
- The code, in a repository the club controls, with the full history.
- Hosting, domain and database accounts in the club's name, paid from the club's account.
- Credentials in a shared password manager that at least two committee members can open.
- Logins registered to a role address such as the secretary's mailbox, not a parent's personal email.
- Regular backups of the data, stored somewhere the club can reach, and one test of restoring them.
- A short document: what the system does, where it runs, what it depends on, how to deploy a change, and what has to be renewed and when.
A second person who has seen it
Documentation helps, but the better protection is a second technical person who has looked at the code and deployed it once. That could be another developer paid for a few hours, or a parent who works in software.
They do not need to maintain it. They need to confirm that the repository is complete, that the instructions work, and that they could make a small change if asked. If they cannot get it running from the documents, you have found the problem while the original developer is still answering messages.
What a handover-ready setup looks like
A new developer should be able to start with three things from the club: access to the repository, access to the hosting account, and the document above. No calls to the person who left, no guessing which server is live. Check this once a year, for instance when the committee changes, along with whose names are on the accounts.
If you find you cannot reach any of it, start with the domain and the data. A developer can rewrite code. Nobody can rewrite your members' registration history.
Weigh the alternative fairly. A rented registration platform removes this risk because the vendor keeps it running, and for a small club with a modest bill that can be the right answer. The cost is a fee that grows with each player, which our software bill calculator, a free calculator, will total over one year and three.
At Hiro our flat monthly price covers hosting, fixes and changes, and the club owns the code and the data and can take both at any time. There is more in our guide to who maintains software you own and on our page for youth sports clubs.