My son came home one afternoon with a QR sticker on his school bag. I had put it there myself the previous weekend, quite pleased with the idea: if he ever got separated from his group on a school trip, whoever found him could scan the code and reach me.
It took about two weeks to realise I had got three things wrong.
None of them were catastrophic. All of them were the kind of mistake you only see once the thing is out in the world, stuck to a bag, being handled by an eight-year-old. Writing them down because I suspect anyone building something similar — for a kid, a pet, a piece of luggage — will hit the same three.
Mistake 1: I encoded my phone number directly
The first version was the simplest thing that could possibly work. I generated a tel: QR code with my mobile number in it. Scan, tap, call. Done.
Here is the problem with that, and it took me embarrassingly long to see it: a QR code on a child's bag is a public object. It sits in a classroom, on a bus, in a playground. Anyone who wants to point a camera at it can, and they do not need a reason. What I had actually built was a sticker that hands my personal phone number to any stranger who is mildly curious.
The number is not the sensitive part on its own — plenty of people have my number. The problem is the pairing. The code links this specific child to this specific number, and it does it silently, with no record and no friction.
What I wanted was for someone who genuinely needs to reach me to be able to. What I built was something quite different.
Mistake 2: I generated a static code
A static QR code has the destination baked into the pattern itself. The pixels are the data. Which means the moment the data changes, the pattern is wrong, and there is no fixing it — you reprint.
I found this out the boring way. I changed a detail — not even the number, just where I wanted the code to point — and the sticker on the bag became a fossil. Still perfectly scannable. Pointing at the wrong thing.
A dynamic QR encodes a short redirect URL instead. The pattern stays constant; the destination behind it is a record you can edit. Same sticker, new target, no reprint.
For anything that lives on a physical object for more than a few weeks, static is almost always the wrong choice. The one exception is a code you genuinely never want to change — a Wi-Fi password on a laminated card, say. A child's emergency contact is the opposite of that. It is exactly the thing you want to be able to edit at 11pm from your phone.
Mistake 3: I only used a QR code
This is the one I want to spend some time on, because it is the part with actual engineering in it.
A QR code needs a camera, an app that reads codes, and a person who knows to open that app and point it at a thing. That is three assumptions. Most of the time they hold. In the specific moment when they matter — someone has found a lost child and is slightly panicked — every one of them is shakier than you would like.
NFC removes all three. The phone is the reader, the reader is always on, and the interaction is "hold the phone near the thing."
What is actually happening on a tap
An NFC tag is a chip and an antenna and nothing else. No battery, no power source, nothing to charge or replace.
When you bring a phone close to it, the phone's NFC radio generates a magnetic field. That field induces a current in the tag's antenna loop — enough current, for a fraction of a second, to power the chip. The chip wakes up, transmits what it is storing, and goes dark again the moment the phone moves away.
The range is about four centimetres. That is not a limitation someone failed to fix; it is the point. A tag that could be read from across a room would be a tracking device. A tag that has to be nearly touching the phone can only be read deliberately.
What the chip actually stores
Very little. A typical NTAG-series chip holds a few hundred bytes.
The data is written in a format called NDEF (NFC Data Exchange Format), which is essentially a tiny container with a type field and a payload. For most real-world tags the payload is a URL, and the type tells the phone "this is a URI, treat it as one." Android sees that and offers to open the link. Recent iPhones do the same without any app at all — NFC reading is always on, there is no toggle to find.
Storing a pointer rather than the data itself is the same insight as the dynamic QR, arrived at from a different direction. The chip holds an address. Everything that matters lives at the address, where it can be changed without going anywhere near the physical object.
Why you still want both
The obvious question: if NFC is better, why keep the QR?
Because NFC hardware is not universal. Most mid-range and above Android phones sold in the last few years have it; plenty of budget models do not. Every recent iPhone does. But "most" is doing real work in that sentence, and the whole point of an emergency contact is that it works for the person who happens to find your kid — not for the person you were imagining.
So: NFC for the phones that have it, printed QR for everything else, both pointing at the same place. Carrying both costs nothing extra and removes the failure case entirely.
What the third version looks like
Everything now points at a page rather than at me.
The page opens with what someone actually needs in that moment: this is a child, here is his first name, here is his school, here is a button to contact a parent. The number is behind the button rather than printed on the sticker. The page is a record I can edit — if a detail changes, I change it once and every sticker pointing at it is current.
The QR is printed. The NFC is a tag behind it. Same destination.
None of this is clever. It is the boring version of the idea, arrived at after building two versions that were slightly too clever. But it is the one that survives contact with an eight-year-old and a school bus.
If you are building something in this space — for kids, pets, luggage, anything that can get separated from its owner — the three rules I would hand my past self are: point at a page, not at a person; make the destination editable; and do not make the finder work for it.
For the version I did not have to build myself, we ended up putting together a family safety profile that handles the page side of it — but honestly, the pattern above is the part worth stealing, whatever you build it with.
Top comments (0)