Conference app launch checklist

The app is not the hard part. Loading content, getting invites delivered and making the schedule true are the hard parts, and each of them takes longer than the software. This checklist is organised by when things must happen, because sequence is what people get wrong, not effort.

One principle sits behind all of it: adoption is decided by the invite, not by the app. An excellent app with a badly worded invite gets ignored. A plain app with a clear invite and one reason to open it gets used.

Twelve weeks out

• Vendor chosen and contract signed.
• Confirm who submits to the app stores, and under whose developer account. Get this in writing. It sets every date below.
• If you are submitting: Apple Developer Program membership active, Google Play developer account created, and someone identified who has done a submission before.
• Named contact at the vendor, with support hours for your event days and a response-time commitment.
• Decide what the app replaces. If the printed programme survives in full, the app will lose.
• Agree the one metric you will judge the app by, and write it down. Usually activated attendees against expected onsite attendance.

Eight weeks out — build the content

This is the longest phase and the one consistently under-budgeted. Content entry for a 40-session conference is days of work, not hours.

• All sessions loaded: title, description, day, time, room, track.
• All speakers loaded: name, photo, bio, sessions linked.
• Rooms named exactly as the venue signage names them. Not “Room 2” in the app and “Windsor Suite” on the door.
• Sponsors loaded, ordered by tier, logos at the right resolution, links tested.
• Theme applied: logo, colours, typography. Check contrast on a real phone in daylight, not on a desk monitor.
• Sessions with capacity limits identified and limits set.
• Decide your photo-album policy now: open, moderated, or admin-only.
• Decide whether the attendee directory is opt-in or opt-out, and make sure the copy attendees see says which.

Six weeks out — the store submission

Skip this section if you are using a web-only app.

• Build submitted to Apple App Store review.
• Build submitted to Google Play.
• Store listing copy, screenshots and icon approved by whoever owns your brand.
• Privacy declarations completed, and consistent with what the app actually collects.
• Allow for one rejection. Almost every first submission gets one, and the timeline should not assume otherwise.

Four weeks out — test on real devices

Not the simulator. Not a screen share. An actual iPhone and an actual Android phone, ideally one of them three or four years old.

• Walk the whole attendee journey: receive the invite email, tap the link, claim the invite, land in the app.
• Do it on a phone that has never seen the app before. The first-run experience is the only one most attendees will judge.
• Check the schedule on a small screen. Long session titles are where layouts break.
• Save a session to the personal agenda; confirm it appears.
• Send yourself a push notification and confirm it deep-links to the right screen, not the home screen.
• Test with the phone on cellular data, not venue Wi-Fi.
• Test with a screen reader for five minutes. You will find something.
• Confirm what an attendee sees if they open the app before the event starts. An empty screen at this moment costs you adoption.

Two weeks out — freeze the schedule

• Schedule frozen. From here, changes are announcements rather than quiet edits.
• Every room and time checked against the venue’s own room booking paperwork. This catches more errors than any other single check.
• Speaker names checked against how the speakers spell them. Then checked again.
• Attendee list cleaned: deduplicated, bounced addresses removed, names cased properly.
• Draft the invite email. Include the one reason to open the app now.
• Draft your first three announcements, so day one is not written on day one.
• Brief the registration desk on what to say when someone has not installed the app.

One week out — invite everyone

• Invites sent.
• Delivery report checked. Chase bounces the same day; a bounced invite is an attendee who will arrive without the app.
• Re-send to anyone who has not claimed after three days, once.
• Confirm the invite renders correctly in the two email clients your audience actually uses.
• Signage prepared with a QR code to the app, for registration and the main entrance.
• Speakers briefed: ask them to mention Q&A in the app at the start of their session.

The invite copy matters more than anything else on this page. Say what the app is for, give one reason to open it today, and make the action obvious. “Build your agenda before the good workshops fill up” outperforms “download our event app” by a distance, because it names something the attendee wants rather than something you want.

The day before — rehearse

• Send a test notification to the team’s phones and confirm it arrives.
• Change a session’s room in the console, confirm it updates on a phone, then change it back.
• Confirm every moderator can log in, from their own device, on venue Wi-Fi.
• Confirm the check-in scanner works at the desk, in the actual lighting, with an actual badge.
• Print the day-at-a-glance and the map. Nothing else.
• Write the incident card: who changes the schedule, who sends notifications, who to call at the vendor, and on what number.

Day one

• Check-in open early. The registration queue is where adoption is won or lost.
• Someone at the desk whose job is helping people install the app, not scanning badges.
• From the stage, in the first ten minutes: what the app is for, and one thing to do in it right now.
• Watch the activation number through the morning. If it stalls, the problem is the invite or the desk, not the app.
• First announcement sent by mid-morning, so attendees learn that notifications carry real information.
• Q&A moderation staffed for every session that has it.

During the event

• One person owns the schedule. Changes go through them.
• Every schedule change is followed by a notification that deep-links to the session.
• Photo moderation queue checked at each break if the album is moderated.
• Watch the arrivals count against the guest list; a gap usually means a scanner problem, not an attendance problem.
• Session feedback prompt confirmed working after the first session of each day.

The five things that actually go wrong

The schedule is wrong on day one. This is the worst failure on the list, because an attendee who is sent to an empty room stops trusting the app and never comes back. Check against the venue’s paperwork, not against your own spreadsheet.

Invites go to a stale list. Bounced invites are invisible unless you look. A per-recipient delivery report is the only way to find them before the attendee arrives without the app.

Room names do not match the signage. Attendees navigate by the door, not by your data model. If the venue calls it the Windsor Suite, so does the app.

Nobody mentions the app from the stage. Ten seconds in the opening session is worth more than three emails. Ask the chair to do it, and give them the sentence.

Notifications are only used for emergencies. If the first notification an attendee receives is a crisis, they had no reason to keep them on. Send something useful on the first morning so that permission is worth having later. There is more on this in push notification best practices.

After the event

• Session feedback exported and sent to each speaker within a week.
• Q&A, polls and photos archived before anything expires.
• Post-event survey out within 24 hours. The question list is a menu; take twelve.
• Activation number recorded against expected attendance, so next year has a baseline.
• One page of notes written while it is fresh: what to keep, what to change, what nearly went wrong.