Changing where a printed code points, after it is printed

The landing page moved. The packaging did not.

This is the single most expensive QR mistake, and it is not a security problem — it is a printing invoice. A static code encodes its destination into the pattern, so changing the destination means changing the pattern, and changing the pattern means the run you already paid for is now pointing somewhere that 404s.

Why a dynamic code can move and a static one cannot

A static code is its content. Scan it and your phone reads the URL directly off the paper; nothing is consulted, nobody is asked. That is genuinely a feature — it works with no connection and depends on no company staying in business — and it is also why it is frozen the moment ink hits the substrate.

A dynamic code encodes an opaque address on our domain and nothing else. The destination is a record behind that address. Repointing is editing the record: the printed symbol is untouched, every scan from that second forward resolves to the new destination, and the boxes stay on the shelf.

What that buys, concretely:

• Edit the destination, keep the code. The payload is a versioned record, so a change can also be rolled back — a wrong URL pushed on a Friday is a revert rather than a reprint.
• Pause instead of breaking. A code can be paused, which is not the same as deleted: scanners get a defined page rather than a dead link, and it can be unpaused.
• Fail somewhere sensible. A destination that stops resolving is detected, and the code can be pointed at a fallback rather than at a browser error.
• Route by who is scanning. Country, device, time of day or a campaign parameter can each send a scan somewhere different, so one printed symbol serves a regional launch without a regional print run.
• Repoint one production run. For codes carrying batch and serial numbers, the routing rule can send a single lot to a recall notice while every other pack on every other shelf still opens the ordinary product page.

A printed code is usually the one thing you cannot patch

Most of a product launch is revisable. The site is a deploy, the ad is a field in a dashboard, the email is a resend. The code stamped on the carton is the exception — it is the only part of the campaign with a lead time measured in weeks and a rollback measured in pallets.

That asymmetry is the whole argument. Everything else in the stack can move; make the immovable thing point at something that can.

Where the guarantee ends

A code on a shelf is not a code you control. Repointing changes what the code resolves TO. It does not reach into the world and un-print it, and it does not un-scan what someone already scanned. Someone who read the old destination yesterday read it.

The destination is not private by being dynamic. A product code is usually marked public on purpose — a shopper holding a bottle in a shop cannot be asked to sign in — and a public code resolves straight through to the destination with nothing to pass. Encryption at rest, workspace binding and destination screening all still apply; the gate does not. The default is gated, and dropping it is a per-code decision you make deliberately.

Dynamic means someone has to be running. The address has to resolve, which is a dependency a static code does not have. It is the same dependency as a short link or a domain name, and it is the price of everything above. Worth stating rather than hiding.

The old destination is still where the old scans went. If the page you moved away from is one you no longer own, it is not yours to make safe. Repoint the code, and take the old page down or redirect it too.

The honest summary

Dynamic codes do not make printing reversible. They make the destination editable, which is the part of a print run that actually changes — usually within a quarter, often before the pallet arrives.

Start from the product page template: a code for packaging or a shelf label, open to everyone, with the destination yours to change afterwards.