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.
Top comments (0)