What is prlx.one?
prlx.one is our QR code and short link service. You print a code once, and you can change where it goes later. The home page puts it in six words: "Print the code once. Repoint it forever."
A normal QR code bakes the web address into the ink. A prlx.one code points at a redirect we run. The destination lives in a database row, so you can edit it from the portal. The flyer you already printed keeps working.
Who is it for?
It is for anyone who prints things and does not want to reprint them. The home page names four uses: business cards, flyers, packaging and email signatures.
Here is an example. A cafe prints one poster for the whole year. In March the code opens the spring menu. In June it opens the patio page. In December it opens gift cards. It is the same poster with three destinations and no reprint. The home page also says "Our own card project runs on exactly this."
We run it ourselves from Battle Creek, Michigan. The privacy page names us as the operator, and the home page says the service "runs on infrastructure we own and operate."
Access is by account. There is no public price list. The home page says to email us and we will set you up.
What does a scan record?
Each scan records when it happened, the device, a rough location, the referring page, the browser language and any campaign tags on the link. The privacy page says "Roughly thirty fields are captured." That is the point of a tracked code. You want to know which flyer got scanned.
It also records the network address the scan came from. The privacy page says it plainly: "Each scan records the network address the request came from, and that address is stored with the event." We say it on the home page too, not only in the policy.
Why say that so plainly?
Because the first draft of our own copy got it wrong. The landing page once said raw addresses were never stored. Then we read the code. It kept them. Our build notes record that the home page, the FAQ and the footer were all corrected to match what the code does.
Then we found a second path. Live scans run through a Cloudflare worker at the edge, not only through the server we had been reading. Our build notes say that worker records the address in three fields. Our call on July 25, 2026 was to keep that and disclose it. So the policy now describes the most that is kept, not the least. The privacy page says many tools in this category "imply the opposite." We would rather not be one of them.
If you need addresses kept out for your codes, the privacy page asks you to tell us before you print.
How long is scan data kept?
It depends on where it sits. On the redirect service, a delivered event is kept for 7 days and a failed one for 90 days, according to the privacy page. Events that have not been delivered yet are never deleted by age, because that copy is the only one.
In the analytics store, scan records stay for the life of the account. That lets you compare this spring's flyer with last spring's. They are deleted when the account closes, or sooner if you ask.
That 7 and 90 day limit did not always exist. Our build notes say delivered and failed rows used to be kept forever. A cleanup job now runs every six hours and once at startup.
What broke along the way?
Search engines could not read the front page. The root of prlx.one used to serve the portal's app shell. Crawlers and link previews saw an empty page and a script tag. There was no text, no description and nothing to index.
The fix was a plain HTML landing page built into the same Go program. There is no build step and no new server. Tests prove the short links still win over the new page, so no printed code broke when the landing page went in.
We also dropped Google Fonts. The privacy page now says the site makes "no third party requests at all."
What did we keep?
We kept the honest version. The site says what a scan records, in the first screen a buyer reads, not on page six of a policy.
We kept the demo honest too. The QR code on the home page points straight at the page itself, not through a redirect. The home page says "scanning it records nothing at all." You can test the idea without being tracked.
And we kept it small. The sitemap lists three pages: the home page, the privacy policy and the terms. The work is in the redirect, not in the marketing.
Why should a business owner care?
Because the same habits run the work we do for clients. We read the code before we write the claim. When the two do not match, we fix the claim. If you trust a team with your email, your website or your data, that is the habit you want them to have.