Comment CiviCRM (Score 2) 104
They should only go with custom code up to a certain extent. The organization should have the freedom to choose its own service provider (including volunteers). I'm probably stating the obvious, but if there is too much custom code they will be forced to spend a lot to rewrite code when volunteers rotate (and most likely will want to roll their own fancier solution), spend a lot of energy/time/money to maintain the code, or have difficulties finding volunteers who want to get involved in such a mess.
I don't know the specifics of your use-case, but CiviCRM is a Free Software contact relationship management software aimed specifically at non-profits. It has a large community of users and developers. While the community mostly operates on non-profit budgets, it includes users such as the FSF, EFF, Wikimedia, sub-orgs of UNESCO, Amnesty International, NY State Senate, etc. I use it for my small local clients, but I'm happy to be able to pool ressources with such organisations.
While turn-key tools can only do so much, you would probably have better chances of customizing that to fit your needs, and in the long term, the organization can turn to specialized service providers if necessary, without restarting from scratch.
Heck, worst case, if your volunteers are PHP-averse and don't feel like spending too much time customizing the application, you can write just a front-end application to it, and use the CiviCRM REST API to store the data. Writing a whole new application just for that seems like a huge waste of ressources, and does not seem sustainable. An event management tool has a ton of small but critical features to think about.
If they think it will be hard to learn an existing generic tool, imagine how hard it will be for new staff/volunteers to use a completely custom tool. Not to mention that if your organisation has an aim of promoting common good, community building, etc, they should also participate in existing Free Software projects