A lead capture app for trade shows lives or dies on what the badge actually encodes.

Which badge codes a phone camera can read

This is the part people worry about, and it is the part already finished. A trade show badge scanner app built with React Native and Expo uses the camera module, and its documented barcode types are qr, aztec, pdf417, datamatrix, code39, code93, code128, itf14, codabar, ean8, ean13, upc_a and upc_e. That matters because badges are not always QR. Plenty of shows still print a linear Code 39 or Code 128, and PDF417 and Data Matrix hold more characters than a linear barcode does. All of them are on the list.

There is one documented caveat worth knowing before you draw the capture flow. Reading a code out of a still image rather than off the live camera, which the module exposes as scanFromURLAsync, supports only QR on iOS, and on Android the code should take up most of the image. So the tempting fallback of photographing every badge and decoding the pile in the evening is weaker on iPhone than live scanning is. If you want a photo fallback, treat the photo as evidence for a person to read, not as a second decode path.

The other practical point is to restrict the types you accept. A scanner left open to every symbology will cheerfully read the barcode on a shipping carton behind the visitor, or a code printed on the stand next door. Set the accepted list to what the show actually prints, and show the operator what was read before the record saves.

Expo, expo-camera barcode type reference

The scan is the cheapest part of the lead

An event lead retrieval app that stores only contacts produces a list nobody works. What makes a list workable is the handful of fields captured next to the scan, while the conversation is still in the room. The vocabulary the shows ship is instructive here. The twenty one preset action codes on that ATD order form mix three different things: the next step, for example send literature, send pricing, provide quote, have salesperson call; the visitor's authority, for example recommends, final say, makes purchase decision; and the timing, for example purchase in 30 days, purchase in 3 months, immediate need.

Three dimensions crammed into one field is exactly why exhibitors end up wanting their own. A code list you cannot change forces staff to pick the nearest wrong answer, and a lead tagged send literature tells the person following up nothing about why. Your own fields can ask the two or three questions your sales team actually sorts on, and can make one of them required so a record never arrives blank.

Then capture the things nobody thinks of until the debrief: who scanned it, which shift, which stand if you run more than one, and a free text note in the visitor's own words. Record what the visitor was told about their details too, because somebody will ask later. None of this is attendee facing. If you also need an agenda, a floor plan and a session list for the people walking the hall, that is a conference app and a separate build.

The hall, the queue and the handover

Two things break exhibitor lead capture on the day, and neither of them is the camera. The first is signal. A show floor is a metal shed holding thousands of people with phones, and the organiser's own terms can be blunt about it: the ATD form states that its mobile app needs either a cellular network or a Wi-Fi connection, while its rented handheld stores leads locally in the event connectivity is interrupted. An app that assumes a network at the instant of the scan fails at the instant you are busiest.

The second is the queue. Twenty seconds a visitor is a long time when four people are waiting behind them. The capture flow has to be scan, two taps, done, with everything optional pushed into a later edit. Build the edit screen for the quiet hour after lunch, not for the rush.

That means the record is written on the device first and synced when it can be, which also gives you duplicate handling for free: the same person scanned twice by two staff is one lead with two notes, not two leads. Getting the queue and the replay right is a subject of its own, and a hall with no signal is where that detail sits. The stand kit has the same shape of problem, since demo units, tablets and rented scanners go out and come back, which belongs in an asset tracking app rather than in the lead list.

What each way of capturing leads gives you

Building one for your own stand

Off the shelf lead capture products are built for teams doing thirty shows a year, priced per user per event, and shaped around whatever the last large customer asked for. A company doing four shows with two people on the stand needs a fraction of that, and needs two or three things the product will not do: the qualifying question your industry actually turns on, the stand rota, the follow up owner assigned at the moment of the scan rather than a week later.

Newly is an AI app builder. You describe the capture flow you want, including the fields your sales team sorts on, and it writes a real React Native and Expo project you own and runs it on a cloud iPhone or Android simulator while it builds. Plans are $25 a month and there is no free plan. iOS ships through TestFlight and App Store Connect with your own Apple Developer account, and Android publishes to Google Play internal testing from the Deploy tab, or builds a standalone production APK you can hand straight to the two people working the stand. What it cannot do is give you the show's attendee database. That still comes from the organiser.

So the order of work is fixed by the badge, not by the software. Ask the organiser what the code contains and what the developer kit costs, then build the capture flow around the answer you get. Doing it the other way round is how exhibitors end up with an elegant scanner and a spreadsheet full of numbers.

Questions exhibitors ask about trade show lead capture

Describe the stand, not the software

Write down what the badge gives you, the two questions your team sorts on and who owns the follow up, and build the capture around that.