An alumni app is a directory people agreed to be in.
An alumni app is mostly one feature with a lot of feeling attached to it: a searchable list of people who once shared a campus. Get that list right and the events, the giving and the mentoring all hang off it. Publish it without asking first and you have shipped a contact database of adults who never agreed to be in it. The stack is the same as the rest of educational app development. The difference is that these are grown-ups, and the institution no longer has a registrar's relationship with any of them.
This page covers what graduates actually open the app for, what opt in has to look like field by field, how events, giving and mentoring stay separate records, and what has to happen on the day somebody changes their mind.
See what one profile shows to whomThe short version
The directory is the product, and consent is the schema.
Two things decide whether an alumni app gets opened a second time. Whether enough graduates are listed for a search to return anybody at all, and whether each of them feels safe being found there. Those two pull in opposite directions, and an app that settles them with a single account wide switch loses both at once.
The way through is consent per field, set by the alumnus rather than by the institution. Name and class year in. Phone number out. Employer visible to signed in graduates but never to the open web. Ask once, at a moment when the question means something, and let the answer be changed later without an email to the alumni office.
Why most alumni apps go quiet a month after launch
Launch usually works. A few thousand graduates install the app, search for two people they already knew, and never open it again. The reason is structural: the app was built around the institution's calendar, and that calendar holds about four moments a year. Between reunions there is nothing to come back for, so the app settles into being a homecoming ticket nobody deletes.
What graduates actually return for is narrower and more useful than the brief usually says. Somebody is moving to a new city and wants three people there to have coffee with. Somebody is hiring and wants a shortlist out of their own programme. A final year student wants to ask a working engineer whether the job is what it looks like from outside. All three are the same query with a different filter: people, by place, by field, by year.
That is why an alumni network app earns its place and a news feed does not. A feed competes with every other feed on the phone and it loses. A filtered list of real people, reachable, kept current by the people in it, competes with nothing. Build the search first and the engagement follows from it rather than from push notifications.
What an alumni directory app may publish, and what it should ask
Start with the legal floor, because it sits lower than most people assume. Under United States student privacy rules an institution designates certain fields as directory information and may disclose them unless the student opts out, after public notice of the fields and of the right to refuse. For former students the rule loosens further: an institution may disclose directory information about former students without repeating that notice and opt out step. An opt out made while the person was in attendance still has to be honoured, unless they rescind it.
So the honest answer to whether a United States institution legally needs consent to list a graduate's designated directory information is often no. That is exactly why this is a design question rather than a compliance question. The same rules let an institution specify that directory information goes only to specific parties, for specific purposes, or both, and then hold it to that limit. An alumni app is a very good place to draw that line. A phone number that was unremarkable on a printed class list in 1998 is a different object inside a searchable app on forty thousand phones.
Which means the profile is not one record with one visibility setting on it. It is a set of fields, each with an audience: hidden, visible to alumni relations staff, visible to signed in graduates, visible to the open web. Search has to respect those audiences too, or a hidden number still leaks out through a result count or an autocomplete suggestion.
Deciding who may see another alumnus is a permissions model, not a privacy policy, and it belongs in the data layer rather than in the screens. Put it in the screens and every new screen reopens the same hole.
34 CFR 99.37, conditions for disclosing directory information
Try it
What one profile shows to whom
Set the audience field by field, the way the alumnus would. The card at the bottom is what another graduate sees.
4 of 6 fields visible
Another graduate sees name and class year, employer and job title, city, open to mentoring. Everything else stays off the card, not greyed out on it.
Events, giving and mentoring are three records, not three tabs
The second common mistake is folding every interaction into the profile. A graduate who came to a reunion, gave once in 2019 and has offered to mentor is three separate facts with three different lifespans. Flatten them into columns on one row and the later questions become unanswerable: who came last year and not this year, who offered to mentor and was never matched, who gave for three years and then stopped.
Associations that charge dues learn this early, because renewal logic forces the structure on them. If a paying membership sits behind your app, the shape is the one a membership management app needs: a person, a tier, a period, and a payment that belongs to the period rather than to the person. Without that, a lapsed member looks identical to somebody who never joined.
Giving has the same shape and a harder audit trail. A gift carries an amount, a date, a designation, a soft credit and sometimes a pledge schedule behind it, which is the job of a donation tracking app rather than a field on a profile. Newly has no built-in payments, so an app like this records and reports on giving while the money itself moves through whatever processor the institution already runs.
Events are records too, and a check in is not the same record as a reply. Keeping them apart is the only way to learn next year whether the people who said yes actually arrived, which is the number that tells you what the app is worth.
What has to happen the day somebody changes their mind
Any institution with graduates in Europe or the United Kingdom holds personal data under the GDPR, and if consent is the lawful basis for the directory then that consent comes with conditions. It has to be a clear affirmative act: freely given, specific, informed and unambiguous. Silence, pre-ticked boxes and inactivity do not count. Where the processing has several purposes, consent has to cover all of them, which is the legal form of the point above. The directory, the fundraising mailing and the careers network are not one checkbox.
The condition that bites hardest at build time is withdrawal. A person may withdraw consent at any time, has to be told so before giving it, and it must be as easy to withdraw as it was to give. If joining took one tap inside the app, leaving cannot require an email to an address somebody reads on Tuesdays. Build the leave path next to the join path on day one. Retrofitting it means hunting down every table and every export that quietly copied the profile.
So, plainly, this is what opt in should look like for an alumni directory. Per field, not per person. Audiences named in the alumnus's own words, so that signed in graduates means signed in graduates and not also the public site. Given by a positive action at a moment the person understands, never by a pre-ticked box in a welcome email. Kept separate from consent to be asked for money. Reversible from inside the app in the same number of taps it took to agree. And stored with a date, because a consent you cannot evidence is a consent you do not have. That is more than United States rules demand for former students, it is close to what European rules require, and it costs one screen.
What each option gives a graduate looking for somebody
| Option | Searchable by year, place and field | Alumnus controls each field | Leaving takes one tap | Events and giving on their own records |
|---|---|---|---|---|
| Printed or PDF class list | No | No | No | No |
| LinkedIn group or alumni page | only members who filled it in | Yes | Yes | No |
| Alumni CRM plus email | staff only | No | ask the alumni office | Yes |
| Off-the-shelf alumni platform | Yes | varies by product | Yes | Yes |
| An alumni app you build | Yes | Yes | Yes | Yes |
Building one around your own graduates
Advancement platforms are built for advancement offices and priced for them, with modules spanning the whole giving pipeline. A single department, a business school, one graduating cohort or a four thousand person association usually needs a directory, events and a mentoring match, plus one or two things no platform will do: a chapter that exists in one city only, a class secretary who edits entries for people who do not use apps, a field for the name somebody graduated under.
Newly is an AI app builder. You describe the app, including which profile fields exist and who can see each one, and it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships it to TestFlight and to Google Play internal testing. It can also build a standalone Android APK with the JavaScript bundled. Plans are $25 a month and there is no free plan. iOS distribution needs the institution's own Apple Developer account. It is not an advancement CRM and it does not arrive holding your constituent data.
Whatever you build it with, write the field list and the audience for each field before you draw a screen. Everything else in a university alumni app, the search, the exports, the consent record, is a consequence of that one table.
Questions people ask about alumni apps
It is a mobile app for the graduates of an institution, built around a searchable directory of them, with events, giving history and mentoring hanging off that directory. The directory is the part that makes it useful. Without one it is a news feed competing with every other feed on the phone.
Write the field list before the screens
List every field a profile will hold, name who can see each one, then describe the app you want built around that table.
Start building