QRPixel: Link in Bio & Dynamic QR Platform We Design, Build, and Run Ourselves

Most people don't have a website. They have an Instagram bio, a WhatsApp number, a booking link, a portfolio, and a QR code on a flyer, all pointing in different directions, none of them talking to each other. The "link in bio" tools that appeared to fix this mostly just became a list of links: a menu, not a hub.

Four gaps kept showing up in the tools already on the market. A link out is a dead end for the page owner. The moment someone taps it, they leave, and the owner learns nothing about which link worked or where the visitor came from. Booking lives somewhere else, bolted on as yet another subscription and yet another link. QR codes are treated as an afterthought. A generator spits out a static black and white square pointing at a fixed URL, and printing it freezes that decision forever. And most link in bio pages hand the owner a generic search engine title and description, with no control over how their own page shows up in search.

For a freelancer, creator, or small business, a link in bio page is effectively their entire web presence. Treated that way, a pile of links stops being good enough. It needs to be discoverable, measurable, and controllable, and a static list is none of those.

We started from one decision we'd defend above all the others: the printed QR code is never the destination, it's a pointer to a destination that can change at any time. A static QR code encodes a URL directly in the pattern, so changing the URL means reprinting the code. QRPixel's codes encode a short, stable QRPixel address that redirects to wherever the owner currently points it. Hand out a business card today, relaunch the whole page next year, and the same card still lands people on the current offer.

Dynamic by default also unlocks measurement a static code can never give. Because every scan passes through QRPixel before redirecting, we attribute it (which code, when, what device) without a third-party tracking pixel following the visitor anywhere afterwards. That first-party posture runs through the whole product: page views, link clicks, QR scans, top links, referrers, and device breakdown are the product itself, not a paywalled report.

We put a bookable calendar directly on the page rather than requiring a second subscription, so a visit can convert without ever leaving. And the page carries a custom SEO title and description the owner controls, instead of a generic one every competing tool hands out by default.

Performance was a design constraint, not an afterthought. A link in bio page that takes three seconds to paint has already lost a share of the taps that reached it. We split the product into a fast public surface that is light and renders immediately, and a richer authenticated app behind it holding the builder, QR designer, contact manager, and dashboard. The page a stranger sees and the console the owner uses have completely different performance budgets, and treating them the same is how products get slow.

We measured one number obsessively while building it: time from "claim your username" to a live, shareable page. The flow is deliberately three steps. Claim your name, build your page with bio, links, and bookable events, then share one link and watch analytics come in. The paywall sits past the moment of value: free forever to claim and publish, no credit card required, with a Premium tier for full analytics, custom branding, and event types.

QRPixel is live in production at qrpixel.net: a link in bio page, dynamic branded QR codes, a built-in bookable calendar, and real-time click and scan analytics, free to start with no credit card required to claim a name.

The dynamic QR decision paid off across the whole product, not just the codes. The page, the links, the booking slots, and the codes are all editable behind a fixed public address, so anything a user commits to the physical world (a printed card, a shop window sticker, a flyer) still points at something they can move later.

First-party analytics turned out to be the better product, not just the harder path: faster pages, cleaner data, and a privacy story we can actually stand behind without a third-party tracker riding along.

Running QRPixel ourselves, with real users, real scans, and real edge cases in production, sharpens how we approach client SaaS builds more than any spec review does. It's one thing to ship a system for a client. It's another to own one ourselves, on call for our own outages, reading our own analytics dashboard to decide what to build next.

For us, QRPixel is the project we point to when a prospective client is deciding between subscribing to an off-the-shelf tool and building the capability into their own platform. We tell people honestly to use a tool like QRPixel when it's for them personally, which is why we built it and made it free. The build conversation is different: a company whose own customers need branded pages, dynamic QR codes, and scan analytics inside their own platform, their own branding, their own data. Knowing which side of that line a client is on, because we've built and operated both, is exactly the judgement this project sharpens.