How to buy an event app: scope it, shortlist, test the hard parts, pilot it, then sign.
Six stages, in order — with the demo script we would want a buyer to run on us: an import of your real spreadsheet, check-in with the Wi-Fi off, a walk-in, a session scan, and the contract questions to ask before you sign.
Written by WebMobi — and marked where WebMobi would fail your test
What this guide is
This is an evaluation plan for anyone choosing an event app for a conference, an association meeting, a training programme or a corporate event. It runs in six stages, and each one produces something you use in the next: a scope, a list of testable requirements, a shortlist, demo results, a pilot verdict and a contract you understand.
Scope the event, not the software
Turn the scope into requirements you can test
Build a shortlist from sourced comparisons
Run the demo script on your own data
Pilot before you commit
Ask the contract questions
We are a vendor, so read it knowing that. Where WebMobi would fail one of your tests, this page says so in “What it does not do” below. If you are still deciding what an event app should do at all, start with what an event app is and the three ways to get one.
WebMobi Event App Builder · Build and launch your event app yourself.
WebMobi Event App Builder is a self-service event app builder that helps conference organizers, associations, agencies and event teams create and launch branded event apps — with registration, check-in (including offline check-in and walk-ins), session attendance, agenda, speakers and exhibitors in one platform.
Stage 1 — Scope the event, not the software
Most evaluations start from a feature list, and a feature list is exactly what every vendor is best at answering. Start instead from the jobs your event needs done, written in your own words. Answer these with the people who will run the event, not only the people who will sign for it:
Who registers, where, and does anyone pay? If tickets are sold, is that already handled by a ticketing system you want to keep?
How many entrances will you check people in at, how many session rooms will you scan, and how many staff phones does that mean?
Does the venue have reliable signal in every room you will use — including the basement hall and the overflow room?
Will people turn up who never registered, and what happens to them at the desk?
How big is the programme, how often will it change after you publish, and who on your team edits it?
What must you hand over afterwards — attendance by session, a record of who checked in whom, a list for follow-up — and to whom?
Write down who operates the system on the day and who signs the contract. They are often different people, and both belong in the evaluation: the signatory cares about the plan and the price, the operations lead about what happens at the desk at opening time.
Stage 2 — Turn the scope into requirements you can test
Sort each job into must-have, should-have and not needed. Then rewrite every must-have as a test with a pass condition. “Offline check-in” is a feature name every vendor will tick; “check in six people with a phone in airplane mode and see all six arrive with the right times” is a test only some will pass.
Requirement
Written as a test
Check-in works without Wi-Fi
With a phone in airplane mode, check in several registered people by QR and by name; reconnect; all of them arrive with the time they were checked in.
Walk-ins at the door
Register and check in someone not on the list in one step; add the same person on a second phone with the same email; they become one registration.
Session attendance
Scan people into one session, one of them twice; the report shows each person once with their visits, and downloads as a spreadsheet.
Import the programme
Import your real speakers and sessions files; your headings are recognised; importing again creates no duplicates.
Shared editing
A colleague changes a session time; the change shows who made it and what it replaced.
Stage 3 — Build a shortlist from sourced comparisons
Build the shortlist from what vendors publish about themselves, with dates, rather than from rankings whose method you cannot see. Our comparisons read each vendor’s own pages, record the date, and score WebMobi by the same rule as everyone else:
Event app pricing — which platforms publish a price at all, and in what unit.
App-store benchmarks — whether each vendor ships an app under your name or a shared one, and when it was last updated.
The evidence behind several of these is our sourced capability matrix of event platforms, where every cell carries the vendor’s own words, a source link and the date it was read. One rule carries over to your own research: a capability a vendor does not mention is “not stated”, not “no”. Ask, rather than eliminating the right vendor for the wrong reason. Three vendors is a workable shortlist — enough to compare, few enough to run the whole demo script with each.
Stage 4 — Run the demo script on your own data
Do not watch a demo; drive one. Ask each vendor for an account you can use yourself — or create one, where the product allows it — and run these tests on your own data. Under each one is how WebMobi does it, so you have one answer to compare the others against.
Test 1. Import your real spreadsheet
Do this: Import your attendee list and your sessions file exactly as your team keeps them — your column headings, your blank cells, your odd rows. Then import the same file a second time.
A good result: Your headings are recognised, rows that could not be imported are reported with a reason, and the second import does not create a second copy of anyone.
How WebMobi does it: Headings such as first_name or company_name are recognised rather than dropped, an import adds and updates but never deletes, and the import troubleshooting guide explains each message.
Test 2. Check people in with the Wi-Fi off
Do this: Let a staff phone load the attendee list, switch on airplane mode, scan two QR codes and check one person in by name. Then reconnect.
A good result: Nothing is lost, every check-in arrives when the phone reconnects, and each one is recorded at the time it happened at the desk — not the time the phone found a signal.
How WebMobi does it: In the WebMobi app, QR check-ins made with no signal are kept on the phone and sent on reconnect, each with the time it was made at the desk, and History marks them as offline. The web check-in page needs a connection. What else works offline on iPhone and on Android is in the platform note below.
Test 3. Register a walk-in at the door
Do this: Someone arrives who never registered. Register and check them in at the desk. Then add the same person, with the same email, on a second phone.
A good result: One step at the desk, not a trip to a laptop — and one registration for that person, not two.
How WebMobi does it: A walk-in is registered and checked in in one step from the Check-In page, and an email already registered for the event is matched to that registration instead of creating a second one. Adding walk-ins in the app is covered by the platform note below.
Test 4. Scan people into a session
Do this: Choose a session, scan three people in, scan one of them out and back in again, then download the attendance for that session.
A good result: Three people, with the re-entry counted as a visit rather than a fourth person, and times in the event’s own time zone.
How WebMobi does it: Staff pick the session in the app or on the web Check-In page; the attendance report lists each person with in and out times and downloads as a CSV.
Test 5. Change the programme after publishing
Do this: Move a session to a different time and room after the event is live, then look at the event page and the app.
A good result: The change shows everywhere attendees look, and you can see afterwards who made it and what the old value was.
How WebMobi does it: You edit a session once and the event page and the app both show it, and the event’s History keeps every content change with its before and after values. A change made directly in the dashboard is recorded without the name of the person who made it — so this test is only a partial pass for WebMobi today.
Test 6. Hand the event to a colleague
Do this: Give a teammate access, have them edit a speaker, and have them run check-in on their own phone.
A good result: Nobody shares one login, and every action — including each check-in — is recorded under the person who did it.
How WebMobi does it: Teammates you make admins can edit speakers, sessions, sponsors and exhibitors, and History records every check-in with the staff member and the device. Content edits made in the dashboard are recorded, but not yet under the editor’s name.
Test 7. Be the attendee for five minutes
Do this: Register on the event page as an attendee would, install the app, find the event, and find your own QR code.
A good result: No confusion about which app or which account, and the code is easy to find in a queue.
How WebMobi does it: People register on your own event page, every registration gets its own QR code, and attendees open the event in the WebMobi app from the App Store or Google Play.
Test 8. Get your data out
Do this: Export the attendee list, the check-ins and the agenda, and open each file.
A good result: Plain files you can open without the vendor, with times labelled by time zone.
How WebMobi does it: Session attendance and the agenda export as CSV files, with times in the event’s own time zone; the agenda names its time zone, so it can be imported back without sessions moving.
Stage 5 — Pilot before you commit
A demo proves the software works for the vendor. A pilot proves it works for your team, in your venue, with your attendees. Run the leading candidate on something real but forgiving — an internal session, a workshop, a smaller regional meeting — or, if nothing suitable is coming up, a full dry run on a practice event with the staff and phones you will use on the day.
Write the pass criteria before the pilot, using the tests from stage 2, and agree who decides.
Put the people who will work the door in the pilot. They will find the problems a buyer does not.
Rehearse the worst case: two phones, no signal, a walk-in added on both, then reconnect and check the record.
Afterwards, export everything you would need to hand over, and check it opens and makes sense.
For WebMobi, the event app builder page walks through setting up an event, and the event-day dry-run guide below includes the two-phone no-signal drill step by step.
Stage 6 — Ask the contract questions
By this point the software question is answered. The contract decides what the answer costs, this year and next. Ask each of these in writing:
Ask
Why it matters
Exactly which capabilities are inside the plan you have quoted?
Many are sold above the base plan. Get the list, not the product brochure.
What is the billing unit?
Per attendee, per event, per year or per module — the unit decides what a second event costs.
What happens when we exceed the allowance?
An overage charge, a hard stop at registration and a forced upgrade are three very different event days.
Who holds the attendee data, and how do we get it out?
Ask for the export formats, and what happens to the data when the contract ends.
Whose name is on the app?
A shared app that hosts many events and an app under your own name are different products.
What support is there on event day, in our time zone?
The hour that matters is opening time at your venue, not the vendor’s office hours.
How does renewal work, and what can change at renewal?
Notice periods and price changes are where a good first year becomes an expensive second one.
Is anything we saw in the demo not live today?
Roadmap features belong in a separate sentence of the contract, or nowhere.
WebMobi’s own answers to the commercial questions are public. We count participants, not events. Run as many events as you like. Every participant who registers counts once toward your yearly allowance, and nothing else does — no charge per event, no charge per ticket, no percentage of what you sell. The plans, the one-off event passes and what each includes are on the pricing page, and the features checklist says plainly which capabilities WebMobi does not have today.
What it does not do
Written down here so you find out now, not on event day.
Attendee networking is not a standard feature
WebMobi networking is in private beta and is not enabled by default. Request activation at /contact-sales or support@webmobi.com.
No ticket payments
WebMobi does not take ticket payments. For a paid event, the event’s button links to the ticketing you already use — test that hand-off in your pilot.
No custom registration questions, discount codes or waitlists
None of these is part of WebMobi’s live feature set today. If your registration depends on them, WebMobi will fail that requirement.
No exhibitor lead retrieval and no badge printing
Only your own check-in staff scan attendee codes. Print badges from your own template if you need them.
No streaming, hybrid attendance or CRM connectors
WebMobi runs the in-person event. Attendance leaves it as CSV files you download.
No app under your own name
Your event runs inside the WebMobi app on the App Store and Google Play; on paid plans attendees see your event’s branded experience.
Offline check-in is in the app, not the browser
The web check-in page needs a connection. Run the Wi-Fi-off test in the WebMobi app, on the phones your staff will use.
History does not yet name who made a dashboard edit
Every content change is recorded with its before and after values, and every check-in with the staff member who made it — but a content change made directly in the dashboard is not yet attributed to the person who made it.
Read the step-by-step guides
The screens, labels and checks for each step are in the product guide on events.webmobi.com.
Long enough to run the demo script on your own data with each shortlisted vendor, and one dry run with the people who will work the door. Start early enough that a failed pilot still leaves time for your second choice.
How many vendors should be on the shortlist?
We suggest three: enough to compare answers, few enough to run every test in the demo script with each of them rather than watching a presentation.
Do we need a formal RFP?
Only if your procurement rules require one. The demo script on this page tells you more than written answers do. If you do need an RFP, our event app RFP questions are free to copy, and each comes with what a good and an evasive answer sound like.
What should we actually test in a demo?
The parts that fail on event day: an import of your real spreadsheet, check-in with the Wi-Fi off, a walk-in, a session scan, a change after publishing, a colleague running the desk, the attendee’s first five minutes, and getting your data out.
Can we evaluate WebMobi without a sales call?
Yes. Create an event and run the demo script yourself, on your own spreadsheets. Book a demo if you would like us to walk through it with you. What each plan includes is on the pricing page.
Should the pilot be a real event?
If you can, yes — a small one where a problem is recoverable: an internal session, a workshop, a smaller regional meeting. If not, run a full dry run on a practice event with the staff and phones you will use on the day.
Does WebMobi pass every test an event app buyer might set?
No. WebMobi does not take ticket payments, has no custom registration questions, discount codes or waitlists, no exhibitor lead retrieval, no badge printing, no streaming and no CRM connectors, and your event runs inside the WebMobi app rather than an app under your own name. WebMobi networking is in private beta and is not enabled by default. Request activation at /contact-sales or support@webmobi.com.
What if a vendor will not put an answer in writing?
Score it as unconfirmed, not as a yes, and ask again before the contract. Anything your event depends on should be either in writing or proven in the pilot.
Run the demo script on WebMobi.
Create an event, import your real spreadsheets and switch the Wi-Fi off — or book a demo and we will run the tests with you.