Case study
An alumni and donations platform for the Bellevue Football Booster Club
Alumni records, recurring giving and supporter communications in one system, run by the volunteers who own it.
01
Executive summary
Arcane Technology Incubator built an alumni and donor engagement platform for the Bellevue Football Booster Club. Organisations use it to manage alumni records, collect one-time and recurring donations, and communicate with supporters — three jobs that had been living in three separate places.
Thirteen functions were demonstrated end to end: alumni search and profiles, a registration workflow routed through approval, full donation checkout through Stripe, recurring monthly, quarterly and annual giving, automated receipts with tax information, dedications for memorial and honour gifts, an admin dashboard, and contact sync to Mailchimp behind an MFA-protected admin panel.
The platform is pilot ready. Production payment and email credentials, a clean launch environment and written onboarding guidance are the four things that close before it runs on real donations.
02
Context and the challenge
Booster clubs and alumni associations run on volunteers, and the work splits badly. Alumni records sit in a spreadsheet, donations arrive through a payment link with no memory of who gave before, and communications go out from a mailing tool that knows nothing about either. The problem being solved here is fragmentation, not a missing feature.
That fragmentation has a cost the club feels directly: nobody can answer who played which position in which year, which supporters give every month, or who should receive the next campaign. Every one of those questions turns into manual work for someone who volunteered to support a football programme, not to reconcile records.
The platform had to hold all three — community, giving and comms — in one workflow, and it had to be operable by administrative staff rather than a technical team. Handover was a requirement of the build, not an afterthought.
03
What we built
Community
Alumni management
- Alumni searchBy name, jersey number and position.
- Alumni profilesPersonal detail, achievements, interests, images.
- Registration workflowSelf-enrolment routed through approval.
- Manual recordsAdmins add alumni without registration.
Giving
Donations and payments
- One-time donationsFull checkout, demonstrated end to end.
- Recurring givingMonthly, quarterly and annual subscriptions.
- Automated receiptsDonor detail plus tax information.
- DedicationsMemorial and honour giving.
Operations
Admin, comms and control
- Admin dashboardApprovals, donations, activity, pending requests.
- Approval workflowApprove, reject, edit, review.
- Mailchimp syncOpt-in contacts flow to campaigns.
- MFA-protected adminSecond factor on the admin panel.
Every function above was demonstrated or directly walked through in session. Nothing on this page is roadmap.
Key decision 1
Registration goes through approval, not straight into the directory
Alumni can enrol themselves, but a self-service directory with no gate is a directory that fills with duplicates, wrong graduation years and the occasional person who never played. For a club whose records are also its donor list, that degrades the asset it depends on most.
So registration was built as a request, not an insert. Every self-enrolment lands in an approval queue where an administrator can approve, reject, edit or review it, and administrators can also create records directly for alumni who will never fill in a form. The dashboard surfaces pending requests alongside donations and recent activity, so the queue is visible rather than something to remember to check.
The cost of the decision is honest: someone has to work the queue. The benefit is that the directory stays accurate enough to fundraise against, which is the reason it exists.
Key decision 2
Recurring giving as the core rail, not an upsell
The obvious build is a donate button. One-time gifts are simpler to implement, simpler to explain and simpler to support. But a booster club's budget is annual and its costs are continuous, and a season funded entirely by one-time gifts has to be re-raised from scratch every year.
Recurring giving was therefore treated as a first-class path rather than a checkbox at the end of checkout. Donations route through Stripe with monthly, quarterly and annual subscription options, receipts are generated automatically with donor detail and tax information, and gifts can be dedicated in memory or honour of someone — the form most alumni giving actually takes.
Stripe was chosen as the payment rail rather than a custom integration: it carries the compliance burden, handles subscription billing natively, and is a name volunteer boards already recognise and trust with card data. In the pilot it runs in test mode; connecting the production account is the first item on the pre-launch list.
Key decision 3
Mailchimp for campaigns instead of building a second email tool
Communications could have been built into the platform: a template editor, a sending service, deliverability monitoring, unsubscribe handling, bounce processing. All of it is well-understood work, and all of it would have competed for the same weeks as the alumni and giving features the club actually asked for.
Instead, opt-in contacts synchronise to Mailchimp and campaigns are built there. The platform owns the record of who the supporters are and what they have given; Mailchimp owns the sending. That keeps deliverability with a provider whose entire business is deliverability, and it means the club's staff work in a tool many of them have used before.
The trade-off is real and worth naming: campaign creation happens outside the product, and audience segmentation needs further configuration on the Mailchimp side before targeting gets precise. Improved segmentation and campaign reporting are the two highest-value enhancements on the list, and both build on this integration rather than replacing it.
04
Where the pilot stands
The platform is developed enough to run with real users, and that is the recommendation: a controlled pilot on the club's own alumni and donation workflows. What it lacks is evidence, not features — adoption and fundraising performance can only be measured once real supporters are using it, which is exactly what the pilot is for.
Four things close before the first real donation goes through. We name them here rather than after launch:
01
Connect production Stripe
Done when a real payment is processed.
02
Configure Mailchimp
Done when contacts synchronise on production credentials.
03
Replace pilot data
Done at a clean launch environment, test records removed.
04
Knowledge base
Done when written guidance ships with the handover.
The live fundraising test is scheduled against a launch event, end to end, on a real transaction. Reporting depth, mobile experience, data migration and scalability under real load are all unmeasured today and sit on the pilot's list to find out, not on this page as claims.
05
Conclusions
The useful lesson from this build is about sequence. Community, giving and communications look like three products, and building them as three products is how a volunteer organisation ends up with three tools that don't know about each other. Holding them in one workflow — one record of who a supporter is, what they have given and what they have agreed to receive — is what makes the administrative work shrink rather than move.
The second lesson is about integration boundaries. Payments went to Stripe and sending went to Mailchimp because both are commodity infrastructure with real compliance and deliverability burdens attached. Building either in-house would have consumed the weeks that went into the alumni directory and the approval workflow, which are the parts nobody else was going to build for this club.
And the honest one: a working pilot is not a validated product. The build is ahead of the evidence, and the next milestone is a real donation from a real supporter, not another feature.
Have a problem shaped like this one?
Tell us what you need built. We scope it in a call and tell you plainly whether we're the right team.