DEV Community: Profile Tap

Your luggage tag is a database record with no primary key

Profile Tap — Mon, 07 Sep 2026 10:26:17 +0000

An airline loses your bag. You file a report. Someone at a counter three cities away eventually finds a black suitcase with no working identification on it.

That gap — between "bag located" and "bag returned" — is not a logistics problem. It is an identifier problem, and it is the same one you hit in any distributed system where two parties hold partial state and neither can resolve the other.

I have spent the last year building profile infrastructure for exactly this kind of lookup, so this post is about what actually breaks in the handoff.

The failure is at the identifier layer

A luggage tag stores a value. Usually a name, sometimes a number, occasionally an address.

That value has three properties that make it useless as an identifier:

It is not unique. "R. Sharma, Mumbai" resolves to a large set. So does most of what people write on tags.

It is not resolvable. A finder holding a name has no lookup mechanism. There is no directory they can query. The value is inert.

It is not addressable at write time. You wrote it in January. Your number changed in March. Every tag you own now holds a stale value and there is no invalidation path.

Compare with what a working identifier needs: uniqueness, a resolution mechanism, and a mutable target. A stamped tag has none of these.

What airlines actually use, and why it doesn't help you

Airlines assign a bag tag number at check-in. That is a proper identifier — unique, resolvable against their system, tied to a PNR.

But it has a scope problem. The identifier is only resolvable inside the airline's system, and only for the duration of the journey. A stranger who finds your bag on a train platform cannot resolve it. Neither can a hotel. Neither can you, once the journey is closed.

You get a working identifier for exactly the window where you least need one, and nothing for the window where you do.

The pointer pattern

The fix is the one you already use everywhere else: stop storing the value, store a pointer to it.

A travel profile is the target. The tag carries a URL encoded as a QR code. The tag itself holds no personal data — it holds an address.

This changes the properties in the ways that matter:

Unique — the URL resolves to exactly one record
Resolvable — any phone with a camera is a client, no app required
Mutable — you edit the record, every tag you have ever printed is now current

The last one is the interesting property. It means the physical object does not need to be reissued when the data changes. You are decoupling the identifier from the payload, which is the same reason you do not store denormalised user data in six tables.

The access-control problem

Now the harder part, and the one most implementations get wrong.

The finder needs enough information to act. You need to not publish your home address to whoever picks up your bag.

Those are in tension, and the naive solution — encode a phone number directly in the QR — solves neither. It is a stamped tag with extra steps, and it leaks your number to anyone who scans it, including anyone who photographs it in transit.

What works is a resolution layer between them:

Finder scans, gets a page — not a data dump
Page exposes a contact action, not contact details
Call or message routes through the system
Your actual number is never rendered client-side

The finder can reach you. The finder cannot save, sell, or reuse your identity. The permission is scoped to the interaction.

This is just capability-based access control applied to a physical object, and it is why "put a QR code on it" is not the whole solution.

What it is not

Worth being direct about this, because the category gets muddled in marketing copy.

This is not tracking. There is no GPS, no beacon, no location. A scannable tag is passive — it does nothing until a human interacts with it. If you want to know where your bag is right now, you want a Bluetooth tracker, and it is a different product with different tradeoffs (battery, range, network density).

This is not recovery. It does not increase the probability that your bag is found. It increases the probability that a found bag gets back to you, which is a different conditional.

Being clear about which problem you are solving matters. A smart luggage tag optimises the return path, not the search path.

The engineering constraints nobody mentions

If you are building or evaluating something in this space:

No app on the finder side. This is non-negotiable. Your resolution client is a stranger in an airport with 4% battery. Any install step and the resolution fails. Camera-to-URL is the only viable path.

Graceful degradation. Print a short human-readable fallback URL under the code. Codes get scratched. Wet cardboard does not scan.

The physical layer is a real constraint. The tag goes through a baggage system designed to move heavy objects quickly. Adhesive fails, laminate peels, thermal print fades. Most failures I have seen are material failures, not software ones.

Don't over-render. The finder's page should load fast on bad airport wifi and show one action prominently. Every additional element is a chance for them to close the tab.

The general shape

The pattern generalises past luggage. Anywhere you have a physical object that needs to be reunited with an owner — a bag, a bike, a laptop, a set of keys, a pet — the structure is identical:

Object holds pointer. Pointer resolves to owner-controlled record. Record exposes an action, not data.

Once you see it that way, "smart tag" stops being a product category and starts being a fairly boring application of indirection.

More on the implementation at ProfileTap.

I watched a physiotherapist lose three referrals to a wrong digit

Profile Tap — Wed, 02 Sep 2026 08:57:42 +0000

A physiotherapist I know writes his phone number on the back of every prescription slip. Ten, fifteen times a day. Last month a patient read a 3 as an 8, called the wrong person twice, and went to a different clinic instead.

That is not a marketing problem. It is a data handoff problem, and it has a fairly boring engineering answer that most professionals never get told about.

I have spent the last year building profile infrastructure for exactly this kind of handoff, so this post is about what actually breaks — and what the constraints look like once you try to solve it properly.

The handoff has three failure modes

When a professional gives someone their contact details, the transfer fails in one of three ways:

Transcription error. Handwriting to human eye to keypad. Every hop is lossy. Ten digits with no checksum means a single wrong character produces a valid-looking number that belongs to someone else. There is no error detection anywhere in this pipeline.
Staleness. A printed card is a snapshot. The moment the clinic moves, the number changes, or a new specialisation is added, every card already in circulation is wrong. You cannot patch distributed physical copies.
Partial capture. People take a photo of the card and never open it again. The data never reaches the contact book, which is the only place it would have been useful.

Notice that all three are properties of the medium, not of the person. Printing a nicer card does not fix any of them.

Pointer, not payload

The fix is the oldest trick in systems design: stop shipping the data, ship a reference to it.

Encode a URL instead of the details. The URL resolves to a profile you control. Now:

Transcription error is gone, because nobody types anything.
Staleness is gone, because the pointer is stable and the target is mutable.
Partial capture improves, because the target page can offer a proper vCard download instead of a JPEG of a card.

This is the same reason DNS exists rather than everyone memorising IP addresses. The indirection layer is the whole point.

Where it gets interesting for professionals specifically is what you put behind the pointer, because a doctor, a freelancer and an insurance agent need three different shapes of the same object.

The shape problem

A generic "digital business card" gives you name, phone, email, done. That is fine for a sales rep. It falls apart the moment the professional has a workflow attached.

Three real examples:

A doctor needs clinic address and timings that differ by day, a way to route new patients differently from existing ones, and often a booking link that is not their personal number. What they do not want is their personal mobile propagating to every WhatsApp group in the neighbourhood.

A freelancer needs portfolio links, a rate or scope enquiry path, and an invoice-ready set of details. The contact info is almost secondary to the proof-of-work.

An insurance or real estate agent needs a document handoff — policy PDFs, listing sheets — plus a review link, because their entire pipeline is referral-driven.

So the profile cannot be a flat key-value dump. It needs to be a typed object with per-type field sets and per-type layout. In our model each profile carries a type discriminator, and the renderer switches on it. Adding a new professional category means adding a schema and a template, not forking the app.

Two transports, one target

The pointer needs to get from the professional to the other person. There are exactly two practical transports today, and you want both.

QR works everywhere with a camera. It is printable, it costs nothing, it survives being photocopied onto a prescription pad. Its weakness is that it needs line of sight, decent light, and a person who knows to point the camera at it.

NFC works by tapping. No camera, no aiming, no light. The card contains a passive NTAG chip with no battery — the reader's field induces current in the chip's antenna and it responds. The data is written as an NDEF record, in this case a URI record.

The two constraints developers usually get wrong:

Range is tiny by design. Roughly 4 cm. That is not a limitation, it is the security model. You cannot passively read a card from across the room.
Coverage is not universal. Plenty of budget phones ship without NFC hardware, and on some the antenna is in an unexpected spot so the tap "misses". So NFC can never be the only transport. Every card needs a printed QR as fallback, pointing at the same URL.

Same pointer, two ways to deliver it. If you only ship one, a predictable slice of your users simply cannot receive the handoff.

What the NDEF record actually holds

Keep it minimal. An NTAG213 gives you roughly 144 bytes of usable memory. That is enough for a short URL and nothing else, which is a useful forcing function — it stops you from doing the thing that seems clever and is actually a trap:

Do not encode the phone number directly. A tel: NDEF record works, and it is a mistake. You have just made the card immutable and permanently tied to one number. Encode the profile URL. The number lives behind it, editable.

Same argument applies to QR. A static QR with contact data baked in is a printed artifact you can never correct. A QR that points to a URL is a pointer you can redirect forever.

The part nobody plans for

Analytics on a physical object. Once the card resolves to a URL you control, you can see how many times a profile was opened and roughly when. For a professional that is genuinely useful signal — which conference actually produced enquiries, whether the cards handed out at a clinic reception get scanned at all.

It also raises the obvious question of what you log. Our position is that the profile owner sees counts and coarse timing, not identity, because the person scanning never consented to anything. The scan is the other person's action. Treating it as tracking data would be the wrong default.

If you are building something similar, the summary is short: ship a pointer not a payload, type the profile instead of flattening it, and always give NFC a QR fallback.

We build this as ProfileTap — profiles for doctors, freelancers and agents among other things. Happy to answer implementation questions in the comments.

I put a QR code on my kid's school bag — here's what I got wrong the first time

Profile Tap — Mon, 24 Aug 2026 10:18:07 +0000

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.

Letting a stranger contact a car owner without giving them the number

Profile Tap — Thu, 23 Jul 2026 12:45:50 +0000

Letting a stranger contact a car owner without giving them the number

There is a small, very common problem in Indian cities that turns out to be a surprisingly good systems design exercise.

A car is parked badly. It is blocking a gate, a driveway, another car. Someone needs the owner to move it, right now. The traditional fix is a phone number written on a sticker on the windscreen.

That works. It also means a stranger — any stranger, forever — has the owner's personal number.

Why the sticker is worse than it looks

Once a number is visible on a windscreen, a few things follow:

It gets scraped. Numbers on vehicles end up in marketing lists.
It cannot be revoked. Change your number and every sticker you own is now wrong.
It has no context. A 2am call could be a genuine emergency or someone who saw the number three months ago.
It is a safety issue for some owners in a way it is not for others. A number attached to a vehicle, at a known parking spot, at predictable times, is more information than most people realise they are publishing.

So the requirement is oddly specific: a stranger must be able to reach the owner, immediately, without ever learning how to reach them again.

That constraint is what makes this interesting.

The naive version, and why it fails

First instinct: put a QR code on the vehicle that opens a page with a "call owner" button, and put the number behind the button.

This solves nothing. The number is still in the page source. Anyone who wants it can get it, and now you have added a scan step for the honest majority while stopping none of the dishonest minority.

Second instinct: put a contact form behind the QR. The stranger types a message, the owner gets a notification.

Better on privacy, useless in practice. The person needs the car moved in the next ninety seconds. They are not filling in a form and waiting for an email. If the fast path is not there, they go back to writing an angry note.

The real requirement is synchronous contact with asynchronous identity — a live call, where neither party's number is exposed to the other.

What actually works: masked call routing

The pattern is well known in cab and delivery apps, but it fits this case cleanly.

You need a pool of virtual numbers. When someone scans the vehicle's code:

Scan resolves to vehicle → owner (server-side, no number in response)
Server leases a virtual number from the pool for this session
Server binds: virtual_number → owner_number, TTL 10 minutes
Page shows a "call" button pointing at the virtual number
Caller dials it. Bridge connects to the owner.
Neither side sees the other's real number.
TTL expires. Binding is torn down. Number returns to the pool.

The owner's phone rings from a number they do not recognise, which is expected and fine. The caller's number is also masked, which matters more than people assume — otherwise you have just moved the privacy problem onto the person who was trying to help.

A few things that are easy to get wrong here:

Pool sizing is a real constraint. Virtual numbers cost money and you only need one per concurrent session, not per vehicle. Sizing follows peak concurrency, not user count. Getting this wrong is how the economics break.

TTL needs to be short but not hostile. Ten minutes covers the "please move your car" case comfortably. Twenty-four hours turns the lease into a persistent channel, which is exactly what you were trying to avoid.

Bindings must be one-to-one within their window. If two people scan different vehicles and get the same virtual number in the same window, you have a routing bug that connects strangers to the wrong owners. This is the kind of bug that is invisible in testing and obvious in production.

The abuse surface you inherit

The moment you build "anyone can make this stranger's phone ring," you have built a harassment tool. This is not hypothetical — it is the predictable outcome, and it needs handling at design time rather than after the first complaint.

What helped:

Rate limit per scanning device and per target. A vehicle should not be reachable fifteen times in ten minutes by the same person.
Let the owner mute a tag. Not delete — mute, with a timer. Overnight, or while parked at home. The scan still resolves, it just shows a message instead of a call button.
Log every session. Not the call content, just the fact of it: which tag, when, from which region. When someone reports harassment you need something to look at.
Do not expose the owner's name by default. "Owner of a vehicle at this location" is enough information for the interaction to work. A name is not.

The general principle: every contact route you create is also an attack surface, and the owner needs a control for it that does not involve peeling a sticker off their windscreen.

Why the identifier has to be permanent

Here is the part that shapes everything else.

The code on the vehicle is physical. It is printed, stuck on, and then it is out of your control. You cannot push an update to a sticker.

That means the identifier it encodes must be permanent, and everything it resolves to must be mutable:

tag_id (immutable, printed)
└── vehicle record (mutable)
└── owner record (mutable)
└── contact routing config (mutable)

Owner changes their number? Update the owner record. Sticker keeps working. Sells the car? Reassign the tag to the new owner, or unbind it entirely. Sticker keeps working — it just resolves to a different place, or to nothing.

If you build the sticker to encode a URL that contains anything mutable — a number, a username, a profile slug that users can edit — you have shipped something that will break, on physical objects you cannot recall.

This sounds obvious. It is not how most QR-sticker products are built, because when you are moving fast, encoding the current URL is one line of code and encoding a stable ID means building a resolver.

The same primitive, different schemas

Once the resolver exists, the vehicle case turns out to be one instance of a general shape:

Object Who scans What they need
Vehicle Someone blocked in Reach the owner, now
Pet collar Someone who found a lost dog Reach the owner, now
Luggage Airline staff, a stranger Reach the owner, eventually
Person Someone you just met Save your contact details

Identical plumbing — permanent ID, mutable record, resolver, contact policy. Only the record schema and the default contact policy differ. The pet and vehicle cases both want urgent masked contact. The luggage case tolerates asynchronous. The person case wants no masking at all, because you are handing the code over deliberately.

Recognising that early saved us from building four products. We build one resolver and four schemas, which is roughly the architecture we ended up with.

What I would tell someone building this

Do not start with the hardware. Everyone starts with the hardware because it is tangible. The hardware is the easy part. The resolver, the masking layer, and the abuse controls are where the actual work is.

Decide your masking economics before you design the UX. If virtual numbers are too expensive at your scale, you will end up compromising the privacy model to make the numbers work, and you will do it late, badly, under pressure.

Assume the sticker outlives your product decisions. Anything printed is a promise you cannot take back. Design as if every tag will still be on a vehicle in five years, because some of them will be.

If you want the non-technical version of this — what actually goes on a vehicle tag and how owners in India use them day to day — I wrote that up separately: bike and car QR code tags in India.

Curious whether anyone has solved the pool-sizing problem more elegantly than "provision for peak and eat the cost." It feels like there should be a better answer than there is.

The link-in-bio problem is a data modelling problem

Profile Tap — Thu, 23 Jul 2026 12:36:06 +0000

The link-in-bio problem is a data modelling problem

Every creator eventually hits the same wall. They have one link slot on Instagram, and more things to point at than one slot can hold. The standard fix is a link-in-bio page — a list of buttons, one per destination.

I have been building in this space for a while, and I think the list is the wrong shape. Not because it looks bad, but because it models the problem incorrectly.

What the list gets wrong

A link list assumes every visitor wants the same thing, so it shows everyone everything and lets them sort it out.

But the traffic through a creator's bio link is not one audience. It is at least three:

A follower who just watched a reel and wants more of the same
A brand manager evaluating whether to send a brief
Someone who met them offline and is checking they are real

These three want completely different data. The follower wants recent work. The brand wants reach numbers, past campaigns, and an email that is not a DM. The offline contact wants a name, a role, and one way to save the contact.

A single flat list serves the follower reasonably and the other two badly. The brand manager, who is the one with a budget, has the worst experience of the three — they came for a media kit and got a menu.

The second problem: identity is not one thing

Here is where it gets more interesting from a modelling perspective.

Most link-in-bio tools treat a person as one profile with N links. That works until the person has more than one context. A creator who also freelances has a creator identity and a professional identity, and those need different content — different links, different tone, sometimes a different name.

The naive solution is multiple accounts on multiple tools. Which means multiple URLs to maintain, multiple things to update, and a mess when something changes.

The better model is one account, many profiles:

account
└── profile (type: creator)
└── profile (type: professional)
└── profile (type: business)

Each profile is a separate addressable thing with its own content and its own share URL. You choose which one to hand out based on context. Nobody sees the others.

Once you have that, the "which audience is this" problem becomes tractable — you are not trying to serve three audiences from one document, you are handing each audience the right document.

The third problem: the URL is the wrong pointer

This one bit us in production and it is the most interesting bit.

The obvious way to build a link-in-bio product is to make each profile a URL, and let the user edit what is at that URL. Fine. But creators change their bio link constantly — new campaign, new launch, new video. So they generate a new link, update Instagram, and move on.

Every time they do that, every previously shared copy of the old link goes stale. The business card from last month. The QR code on a flyer. The link a brand saved in a Notion doc in March.

The fix is to separate the identifier from the content:

The identifier is permanent. Once shared, it is out of your control forever — treat it as immutable.
The content behind it is mutable and versioned.

This sounds obvious written down. It is not how most of these tools are built, because when you are shipping fast, "let the user make a new link" is easier than "make the existing link always correct."

The practical consequence is that anything physical — a printed card, a sticker, an NFC tag — only works if you have made this separation. You cannot reprint a thousand cards because someone changed a link.

Where NFC and QR actually fit

I want to be careful here, because "NFC business card" gets pitched as a gadget and it mostly is not.

NFC and QR are just two more ways to resolve the same identifier. Tap a card, scan a code, click a link — all three land on the same profile. The tag is not the product. The stable identifier is the product; the tag is one physical way to hand it over.

Once you see it that way, some things that seemed like separate products collapse into one:

A creator's link-in-bio
A professional's digital business card
A pet tag that resolves to owner contact details
A sticker on a vehicle that lets someone reach the owner
A luggage tag with travel contact info

These are the same primitive — a permanent identifier, a mutable profile behind it, a physical or digital way to resolve it. Only the profile schema differs.

That is roughly the architecture we ended up with at ProfileTap: one account, several profile types, one permanent link per profile, and NFC or QR as optional physical resolvers on top.

What I would tell someone building this

Three things I would get right earlier if I were starting again:

Make the identifier immutable from day one. Retrofitting stability into a system where users expect to regenerate links is genuinely painful. Decide early that a shared link is a promise.

Model profiles as first-class, not as a settings toggle. The moment a user needs two contexts, a "profile type" dropdown on a single record starts leaking. Separate records, separate URLs.

Design for the visitor you are not thinking about. Everyone designs for the follower because that is the loudest audience. The brand manager with a budget is the quiet one, and they leave silently when the page does not have what they need.

The bit that surprised me

I expected the hardest problem to be the tags — hardware, encoding, browser support, NFC availability on iOS. It was not. That stuff is fiddly but bounded.

The hardest problem was convincing people that a link they cannot change is a feature. Everyone's instinct is that flexibility is good and permanence is a limitation. It takes one experience of a dead link on a printed card to flip that, and until then it reads as a missing feature rather than a design decision.

If you are curious about the content side of this rather than the architecture — what actually goes in a creator profile that a brand will act on — I wrote that up separately: Instagram collaboration bio: what to write when you want brand deals.

Would be genuinely interested to hear how others have handled the immutable-identifier problem, especially anyone who has shipped something physical that points at a mutable resource. It feels like a solved problem in theory and a mess in practice.

Building a Lost-Pet Recovery System with NFC + QR: A Practical Architecture

Profile Tap — Tue, 14 Jul 2026 07:55:50 +0000

A metal tag engraved with a phone number has three failure modes: the number changes, the engraving wears off, and the finder has to call a stranger.

Better model: make the pet's collar a URL.

The tag is a pointer, not the data

Don't store data on the tag. An NTAG215 chip holds ~504 bytes — enough for a URL, not a profile. And you could never update it.

Instead:

NFC tag  ->  https://example.com/p/{pet_id}
QR code  ->  https://example.com/p/{pet_id}

The tag is a pointer. The profile lives on the server. That gives you mutable data (owner changes their number, no new collar), scan analytics, field-level access control, and revocability.

The physical tag becomes dumb infrastructure. That's the point. This is the model we use for ProfileTap's pet ID tags.

Why NFC and QR

They're not redundant — they cover different failure modes.

NFC wins when:

It's dark — no camera, no aiming
The surface is scratched or dirty
You want a one-second, zero-thought interaction

QR wins when:

The finder's phone has no NFC chip
The finder doesn't know what NFC is, or where to tap
The tag is behind glass, or out of tapping reach

In India, a large chunk of phones don't have NFC. Ship NFC-only and half your finders can't use it. Print both on the same tag. The QR is your fallback — and fallbacks aren't optional when the failure mode is "the pet doesn't come home."

The same dual NFC+QR approach applies well beyond pets — we use it for vehicle windshield tags and luggage tags too.

Writing the tag

NDEF is the standard. One record, type URI:

const ndef = new NDEFReader();
await ndef.write({
  records: [{ recordType: "url", data: "https://example.com/p/abc123" }]
});

Lock the tag after writing. NTAG215 has a one-way lock bit. An unlocked tag can be overwritten by anyone with a phone — including someone who doesn't want the pet returned.

Design for a stranger, not the owner

The person scanning is a stranger who found a scared animal on the road. They have ~30 seconds of patience.

No login. No app install. Web only.
One primary action above the fold — a big "Call Owner" button.
Server-render it. They may be on weak 3G on a roadside.
No home address. Anyone who scans a stray tag would then know an address and that the resident owns a pet. Keep it server-side.

Location: ask, don't take

Tell the owner where the pet was found:

navigator.geolocation.getCurrentPosition(
  (pos) => notifyOwner(pos.coords.latitude, pos.coords.longitude),
  () => {} // declined - degrade gracefully
);

But never gate the phone number behind the permission prompt. A system that holds the pet's rescue hostage to a browser dialog is a system that fails.

Privacy is the whole product

A scannable public URL is, by definition, a public URL.

Non-sequential IDs — random base62, not auto-increment. Enumeration should be pointless.
Rate-limit by IP — someone hitting 500 profiles isn't looking for a lost dog.
Call masking — route calls through a proxy number so the owner's real number is never exposed. We wrote about this pattern in more depth here.
Log every scan so the owner can see the history.

Wrapping up

The stack is boring — a URL, an NDEF record, a server-rendered page, a notification queue. That's a feature. The hard parts aren't technical; they're the 30 seconds of attention you get from a stranger on the roadside.

We're building this at ProfileTap — NFC + QR smart profiles for pets, vehicles, families and businesses, built India-first.

How did you handle the location-consent tradeoff? Drop a comment.

Your Instagram Bio Has One Link — Here's How Creators Make It Do the Work of Ten

Profile Tap — Thu, 02 Jul 2026 09:43:26 +0000

If you create anything online — code, content, art, a side project — chances are you have a social bio with exactly one clickable link. And chances are you're wasting it.

Instagram gives you about 150 characters and a single link. Most people point that link at one YouTube video or a static list they set up two years ago and never touched again. That's a dead end for the person who clicked — and a missed opportunity for you.

Here's how to think about both parts.

** The 150 characters**: say one thing clearly

The biggest bio mistake is being vague. "Content creator | lifestyle | travel | food" could belong to ten thousand people. It tells a visitor nothing.

A strong bio usually has four things:

A specific niche — what you do, for whom. "Budget travel for Indian students" beats "travel lover."
A reason to follow — what does the visitor get? Knowledge, entertainment, inspiration.
A bit of proof — a number, a credential, a feature. It signals you're worth the follow.
A call to action — tell people what to do next. "Full guides + collab info 👇"

Specific beats broad every single time.

The one link: make it dynamic, not static

This is where most creators leave value on the table. A link to your YouTube homepage sends someone to your channel — and then what?

Instead, that one link should open a smart profile that does several jobs at once:

Links to every platform you're active on
Shows your niche and audience size
Holds your booking/contact info
Connects to your media kit
Updates automatically when anything changes

** Why "dynamic" matters (the tech bit)**

A static link page is frozen — every update means editing it by hand. A dynamic profile flips that: the link (or an NFC tag) points to a single URL, and the content behind that URL is editable anytime. Change a campaign, drop a new video, update your rate — the link stays the same, the destination updates instantly. Edit once, reflected everywhere.

That's also why NFC + smart profiles are showing up in the creator world: tap a card at a brand event, and the other person gets your entire identity, always current — no reprinting, no dead links.

Want the templates?

If you want ready-to-use bio formulas by niche — travel, food, fitness, finance, fashion, tech, and more — there's a solid breakdown with 10 examples here: Best Instagram Bio Ideas for Creators. Steal the structure, swap in your niche and numbers.

And if you want the "one smart link" part done properly, [ProfileTap's creator identity] is built exactly for this — one link that holds all your platforms, media kit, contact, and NFC sharing, launching soon in India.

The takeaway

Your bio is the hook. Your link is the net. Most creators write a decent hook and then attach a broken net. Fix both — be specific in the text, and make the link a living profile instead of a dead end.

Lost Luggage, Found Fast: The Tech Behind Smart NFC Travel Tags

Profile Tap — Thu, 02 Jul 2026 09:15:36 +0000

Imagine a small tag on your bag. Someone finds it, taps it with their phone (NFC) or scans the QR code, and instantly sees a secure digital travel profile — showing only what you chose to share:

“Please call this alternate number”
Emergency contact
Blood group / medical notes (optional)
A message to the finder

Your full personal data stays hidden. The finder gets just enough to help.

How it works (the tech)

Under the hood it’s simple:

An NFC chip (like an NTAG213/215) stores a single URL.
A QR code encodes the same URL as a fallback — so even phones without NFC can scan it.
That URL opens a dynamic profile page.
The owner controls which fields are visible — and can update the destination anytime without reprinting the tag.

Because the data lives on a page (not on the chip), you edit once and every tag updates. Reusable, editable, privacy-first.

Real use cases

Lost luggage: finder scans → contacts you without seeing your home address.
Kids’ bags: a tag on a child’s backpack for crowded stations and tourist spots.
Elderly parents / pilgrimage travel: emergency + medical info during Char Dham, Kumbh, or long journeys.
Solo travellers: a safe “if found” contact without doxxing yourself.

** Where ProfileTap fits **

This is exactly what ProfileTap is building — an India-first NFC + QR travel profile that’s reusable, editable, and privacy-first.
Launching soon, it lets travellers share only what they want, update details anytime, and turn any bag into a smart, findable one.

As travel keeps growing, paper tags will feel as outdated as paper tickets. Smart identity tags — tap or scan — are where things are headed.

I Stopped Writing My Phone Number on My Car Windshield — and Built a QR Sticker Instead

Profile Tap — Fri, 19 Jun 2026 10:35:37 +0000

For two years, my windshield had a laminated card: "In case of blocking, call 98XXXXXXXX."
It made sense. I park in tight lanes — someone always needs to move my car. A number on the dashboard solves that.
It also created a problem I didn't see coming until the spam started.

The problem wasn't the sticker. It was the number.
Once your personal mobile is sitting on a windshield in a public lot, it isn't private anymore. Anyone can copy it. I started getting loan spam, a late-night "saw your car" message, random WhatsApp adds.

And I couldn't take it back. Every photo someone snapped of my dashboard still had my number on it. That's the part nobody talks about: a contact detail printed into the real world never expires.

What I actually wanted
A way for a stranger to reach me about my car without ever seeing my real number.

So I built a small thing: a QR sticker for the rear windshield.

Stranger scans QR
→ opens vehicle profile (no number shown)
→ taps "Call" or "WhatsApp Owner"
→ routed through a proxy
→ owner's real number stays hidden

Change the destination number anytime. The sticker never changes.

The privacy layer was the real work — not the QR
Generating a QR is three lines. The actual engineering was the masked contact routing:

Call masking: the button dials a proxy that forwards to me. The
scanner sees the proxy, never my SIM.
WhatsApp first: in India nobody wants a cold call about a parked car — they want to fire off a quick "gaadi hata do" message. So WhatsApp had to be primary, masking on top.
Revocable: sell the car, detach the profile. The contact was never baked into the physical tag.

If you've built anything with personal data in India, the lesson is familiar: **privacy can't be bolted on later. It has to be the foundation. **The moment "hide the number" became the core instead of an add-on, the whole design got simpler.

India-specific things I had to get right

WhatsApp is the channel, call is secondary. Build the masked WhatsApp flow first or you've built the wrong product.
Monsoon-proofing: UV-resistant vinyl + laminate coat, QR recessed so the print survives sun and rain.
No app for the scanner. The person scanning your car will never download anything. QR opens in any default camera; budget Androids mostly don't do NFC.

What I'd do differently
Build the privacy layer first — before the profile UI, before the sticker. I made the page look nice and retrofitted masking, which is backwards. In India, the privacy layer is the product.
I eventually folded this into ProfileTap's vehicle profile, since the same masked-contact idea applies to pets, luggage, and family tags too — anywhere a stranger needs to reach you without owning your number forever.

If you've shipped anything that puts contact data into the physical world — a tag, sticker, NFC card — how did you handle the "this is now permanent and public" problem? Curious how others think about it for the Indian market.

How I Built a QR-Based Pet ID System in India — And the Privacy Problem Nobody Talks About

Profile Tap — Fri, 29 May 2026 08:00:10 +0000

A dog went missing in our neighbourhood in Pune. The owners had a metal tag — name, phone number, engraved. Someone found the dog. Called the number. Disconnected. They had switched SIMs six months earlier.
The problem wasn't the tag. It was that the tag was static.

What We Built
Every pet gets a unique QR code linking to a live profile:
https://profiletap.io/in/blog/best-pet-id-solutions-indiaFinder scans with any camera app — no app install, no NFC needed. Profile opens instantly with pet name, breed, medical notes, and a contact button.
Profile is editable anytime. Change your number once — every tag ever printed reflects it on the next scan.

The Part Most Pet ID Systems Skip: Privacy
If you show a raw phone number on the profile, you've solved one problem and created another. Anyone who scans now has the owner's personal mobile permanently.
Our solution: masked contact routing.

Finder clicks "Call" or "WhatsApp Owner"
Routes through a proxy — owner's number never exposed
In India, the WhatsApp button gets used 3x more than the call button

We almost skipped WhatsApp masking in v1. That would have been a mistake.

India-Specific Problems We Hit
QR size: Tags are 25–35mm. Short URLs + Level M error correction = scannable at small sizes.
Monsoon-proofing: UV-resistant PVC with laminate coat. QR recessed so laminate protects the surface.
Device compatibility: Tier 2/3 cities = low-end Android, no NFC. QR works on any camera. NFC doesn't.

What I'd Do Differently
Build the privacy layer first, not last. And always test on a ₹8,000 Android before launch — that's where the real edge cases live.

Live at
profiletap.io/pet-id-profile
Physical QR tags delivered across India. Free profile to start.
Happy to answer questions about QR implementation or contact masking in the comments!

ProfileTap — smart digital identity for Indian professionals, pets, vehicles, and families.

I built a QR-code safety tag for my kid’s school bag — the privacy problem became the interesting part

Profile Tap — Sat, 16 May 2026 07:34:35 +0000

My 7-year-old started school this year and still doesn’t remember my phone number by heart.

The school suggested putting a contact sticker on the bag, but that meant my personal number was visible to literally anyone handling the bag during pickup, transport, or playtime.

That felt like a weird privacy tradeoff.

So over a weekend I built a tiny QR-based “family safety profile” system for him.

The architecture ended up being more interesting than I expected.

The setup:

One profile per family member
First name only
Emergency contacts
Safe-to-share medical details (blood group, allergies)
One-tap “I found this child” action
Mobile-first web profile that opens without installing an app

The hardest part was contact privacy.

If a random adult scans the QR, they should be able to reach the parent instantly — but they should NOT see the parent’s personal number.

I solved this using a routed communication layer with WhatsApp Business APIs and masked contact forwarding.

That design choice changed the whole product.

A lot of existing emergency-tag products expose raw phone numbers directly. In India, that quickly turns into spam and privacy issues.

The hardware side was intentionally simple:

Laminated PVC tag
Riveted onto the school bag strap
Waterproof enough for monsoon + daily school abuse

A few friends asked if they could use the same setup for:

autistic children
elderly parents with dementia
pets
kids commuting alone

That eventually turned into a small side project called ProfileTap Family Safety Profiles.

The biggest technical lesson for me:
privacy primitives are not “extra features” in India — they are the product.

Curious if anyone else here has shipped a tiny side project that unexpectedly became useful in the real world.

More from ProfileTap:

Why Your Developer Side Project Needs a Smart Identity Profile (Not Just a GitHub README)

Profile Tap — Sat, 09 May 2026 06:01:27 +0000

Most developers building side projects have the same identity problem:

GitHub for code
LinkedIn for resumes
Twitter/X for thoughts
WhatsApp for actual conversations

None of them connect cleanly.

And when someone meets you at a hackathon, startup event, or online community and asks:
“What are you building?”

…there’s usually no single professional profile to send.

A GitHub README explains the project, but not the person behind it. It doesn’t handle consulting inquiries, creator links, or separating personal contact details from public networking.

This becomes more obvious in India, where professional communication is heavily WhatsApp-first and QR sharing is already normal because of UPI adoption.

What actually helped me was using a dedicated identity profile setup:

one profile for consulting
one for creator/content work
one for personal networking

plus QR/NFC sharing for offline events.

I’ve been using ProfileTap for this because it supports multiple identity contexts under one account along with QR sharing and WhatsApp masking.

The free tier is enough for most developers or founders getting started.

If you’re already attending events, freelancing, or building publicly, having a clean professional identity layer matters more than most people realize.