Can you prepare tags before you know the content?
Yes, and doing so is the most useful production habit available. Write a unique address on your own domain to each tag now, apply them, and decide later where each one redirects. The tags are finished before the content exists.
The pattern
Instead of writing the final destination to each tag, write an address on a domain you control, with an identifier that distinguishes one tag from another. Your server decides where that identifier leads.
The tag is then permanent and the destination is not. Encoding, printing and application can all happen before anyone has decided what the campaign says, and changing the destination later is a database edit rather than a field visit.
Why it changes production
Three constraints disappear at once, and they are the three that make tag projects painful.
Content no longer blocks production. Tags can be written and applied while the destination is still being argued about, which removes the dependency that usually delays everything.
Mistakes stop being permanent. A wrong destination on a thousand applied tags is a correction at the server rather than a thousand replacements.
And tags can be locked safely. Locking a tag holding a redirect address is a real option, since the address never needs to change, which is not true of a tag holding the destination directly.
This is what makes locking sensible
Locking is usually a bad idea because content changes. Locking a tag whose content is a stable pointer removes that objection, and gives you tamper resistance at no cost in flexibility.
What you need to set up
A domain you control, a way to map an identifier to a destination, and a record of which tag carries which identifier.
That last point is the one people skip and regret. If nobody knows which tag holds which identifier, you can change destinations and you cannot tell which physical object you are changing, which loses most of the benefit.
Keep the identifiers short. Every character is a byte on the tag, and a short identifier is also easier to write on a label during assembly.
Where it does not apply
Anywhere the tag has to work without a network. A redirect is a link, and a link needs coverage, so this pattern is unavailable for tags meant to work offline.
For contact details handed over in poor coverage, for equipment tags in a basement, for anything where offline operation is the point, the content has to be on the tag and the flexibility is lost. That is a real trade rather than an oversight.
It also creates a dependency on your own infrastructure. If the domain lapses, every tag deployed under it stops working simultaneously, which is a failure mode worth planning for rather than discovering.
Frequently asked questions
Does this work with a URL shortening service?
It works and it creates a dependency on a company you do not control. If that service closes or changes its terms, every tag stops. Your own domain removes the risk for a trivial cost.
Can I change the destination for a single tag?
That is the entire point, provided each tag carries its own identifier. Tags sharing one address can only be changed together.
Is a redirect slower for the user?
It adds one hop, which is imperceptible on any normal connection. The reliability gain is worth far more than the milliseconds.
What if I do not have a website?
A domain and a redirect service are inexpensive and require no site. What matters is owning the domain, not building anything on it.