We Tried to Build a Better Link-in-Bio. The Category Wouldn’t Let Us.

When we started building EdgeURL, the elevator pitch was easy. “Like Linktree, but with built-in URL shortening and analytics.” That sentence got us into investor meetings, got us our first users, and felt like the natural way to describe what we were doing.

About six months in, the sentence stopped working. Not because it was wrong, but because every interesting thing we shipped broke out of it. The integrations with verification systems, the discovery directory, the AI agent tokens, the cross-surface identity graph: none of these things lived inside the “link-in-bio” frame. They were the actual product. The frame was the wrapper we were trying to outgrow.

This essay is about the three structural reasons we couldn’t stay in the category, and what we think the category should be called instead. If you build for creators, run a creator-economy company, or you are a creator getting frustrated with the tools, you have probably been bumping up against these same constraints without naming them.

The original sin: a page, not an identity

Link-in-bio is a category named after a UI affordance. Instagram allowed one link in the bio. Tools sprang up to put many links behind that one slot. The category’s name is literally the location of the workaround.

The problem with starting from a UI affordance is that the abstraction it produces is the wrong one. A link-in-bio page is a single rendered document. You build it, you share it, your audience clicks through. The tool’s job is essentially formatting and hosting.

That model works fine if the underlying entity behind the page is also a single document. But the entity behind the page is a person, and a person has continuity. They show up on Instagram and TikTok and YouTube and X and Threads and Bluesky and Substack. They have a name, a verified identity, a body of work, a way of being booked or contacted. None of that fits inside a single page.

Watch what happens when a creator verifies a social handle on a link-in-bio tool. The verification is stored as a flag on that page. It does not propagate to the short links they create on the same tool. It does not propagate to their booking form. It does not propagate to the OG card that renders when somebody shares one of their short links on Twitter. The same human, having proved the same fact about themselves, has to re-prove it on every surface the tool exposes.

This is not a feature gap that a roadmap can fix. It is a consequence of the page-shaped abstraction. The tool was built around the page; identity is an afterthought attached to the page; the page does not know about other pages.

The reframe: identity has to be the primitive, and the page has to be a view of the identity. The bio page, the short links, the booking form, the OG cards, the contact page: all of them should be rendered surfaces of the same underlying identity graph. Verify a handle once, and every surface that asks knows.

The discovery gap

Here is a question I started asking creators after we shipped our directory.

“Where did your last new follower come from?”

The answer almost never involved a link-in-bio. New followers come from algorithm-mediated content (a video went out, a post got picked up), from shared work (someone reposted a song, a friend dropped a recommendation), or from a directory of some kind (a podcast app, a music platform’s discovery feed, a niche creator catalog).

Now compare that to where existing followers go: directly to the link-in-bio. The page sits at the very center of every creator’s funnel. It is the highest-trafficked single URL most creators own. And it contributes zero new audience.

That is a strange property for the central page of a creator’s web presence to have. The page processes traffic, it does not generate traffic.

Tools in the category have not solved this because they cannot solve it inside the page abstraction. A page that is hidden by design (you can only reach it if someone hands you the URL) cannot also be a discovery surface. The architecture forbids it.

The reframe: discoverability has to live in the same data layer as the identity. A directory of creators indexed by category, verification, and signal is the same database query as the identity graph. The discovery loop and the routing loop close on the same underlying entity. Audience finds the creator through the directory; the directory and the bio page are views of the same identity; clicks compound back into the signal that ranks the directory.

We shipped this as /discover. New audiences find creators by category. The same data that powers the bio page powers the discovery page. They are the same underlying record.

The agent gap nobody is talking about

This is the constraint that I think will matter most in the next eighteen months and that almost nobody in the category is taking seriously yet.

AI agents are about to be the third type of user on every creator’s stack. Not human audience. Not the creator themselves. A third principal: an agent that the creator has hired to do work on their behalf. Updating the bio when a new song drops. Replying to inquiries during a tour. Keeping the store inventory in sync with the merchandiser. Synthesizing analytics into a weekly update.

The bio tools in the category were built before this third principal existed. They have no place to put an agent. The creator’s options today are:

1. Share the full account password with the agent (terrible security, no audit, no revocation, no rate limit).
2. Manually approve every action the agent wants to take (defeats the point of automation).
3. Skip the agent entirely (loses the leverage the agent would have provided).

The tools that will survive the next two years are the ones that treat agents as first-class principals with their own tokens, their own scopes, their own rate limits, their own audit trail, their own revocation page. Anything else is going to lose the customer to whichever tool lets a creator’s agent actually do the work.

The reframe: identity is the primitive, the page is a view, and a third class of consumer (the agent) authenticates against the identity with explicit scoped permissions. Same model that B2B SaaS has used for API tokens for fifteen years, finally applied to the creator tier.

What this changes

If the three reframes above are right, the implication is that “link-in-bio” is the wrong name for the thing we are building, the same way that “search box for the internet” was the wrong name for Google. The page is a piece of the product. The actual product is the identity graph underneath, the discovery surface that closes the loop, and the agent layer that lets work happen autonomously.

We called the new framing a social identity platform. The name matters less than the model. Other companies will land on different names; the structural insight is what carries.

If you build for creators, the question I would ask is whether your roadmap is still inside the page abstraction or whether it has graduated to identity-as-primitive. The category is going to bifurcate over the next two years between the tools that made that move and the tools that did not.

If you are a creator, the questions worth asking your current tool are: does my verified identity propagate to every surface this tool exposes? Does this tool route new audience to me, or does it only process audience I already have? Can I grant a scoped revocable token to an AI agent without sharing my password? If the answer to two of three is no, the tool you are using is structurally going to lose to one that answers yes to all three.

We have a longer product-side writeup of the platform that introduces this from the other direction, if you want the system-design pass: https://edgeurl.io/blog/from-link-in-bio-to-social-identity-platform

Thanks for reading. If you have a take on which of these three constraints bites you hardest, I would be interested to hear it in the responses.