Sooner or later, a client asks for QR codes. It usually arrives as a small add-on to a bigger job like a restaurant website, a product launch or an event page.
It sounds like a five-minute task and that is exactly why it goes wrong. Most developers pick the first business QR code generator that appears in search, export a PNG, send it to the client and move on. The problems show up months later, after thousands of codes have been printed and the project is long closed. By then, the client calls you, not the tool.
Here is what is worth checking before you commit a client to any QR code platform.
1. Static or dynamic and does the client understand the difference?
A static code stores the final URL in the pattern itself. It never expires, but it can never be changed either. A dynamic code stores a short link that redirects to the real destination, so the destination can be edited later.
Most clients want dynamic without knowing it. They will change their menu, move their landing page, or end a campaign. Explain the trade-off in one sentence before you choose because it decides everything else on this list.
2. Who owns the short link?
With a dynamic code, the URL inside the pattern usually belongs to the tool's domain. That means every printed code depends on that company's servers.
Check whether the tool supports a custom domain, so the encoded link lives on something like go.clientdomain.com. If it does not, make sure the client knows their printed material is tied to a third party.
3. What happens when the plan ends?
This is the question that causes the most damage when nobody asks it. Some tools keep redirecting after a downgrade. Others stop redirecting the day a payment fails and every printed code on every table, box and poster stops working at once.
Look for the answer in the pricing page or terms, not in a sales chat. If it is not written down, assume the worst.
4. Export formats that print shops actually accept
A PNG is fine for a website. For print, you want SVG or EPS, so the code stays sharp at any size. Check that the export keeps the quiet zone which is the blank border around the code. Designers often crop it to make layouts tidier and scanners fail without it.
5. Error correction, especially with logos
QR codes can still scan when part of the pattern is covered but only up to the error correction level they were generated with. If the client wants their logo in the middle, the tool needs to let you choose a higher level. A logo placed on a low-correction code looks fine on screen and fails on half the phones in a real shop.
6. Can you get the data out?
Imagine the client has 150 codes six months from now and wants to switch tools. Can you export a list of every code with its destination? If the only way out is copying links by hand one at a time, the client is locked in, whether anyone intended that or not.
7. Bulk creation and an API
One code for a menu is easy. One code per product across 300 SKUs is a different job. If there is any chance the client will scale, check for CSV upload or an API before you start, not after the first batch.
8. Analytics and privacy
Most dynamic tools count scans and some collect far more: location, device, IP address. That data may need to be mentioned in the client's privacy policy, depending on where they operate. Know what is collected before you hand the dashboard over.
A five-minute test before handover
Before you sign off, print one code at its real size on the real material. Scan it with at least three different phones, in poor lighting from the distance a customer will actually stand. Then change the destination in the tool and scan again to confirm the update works.
It is a small step and it catches most of the problems above before they reach print.
Wrapping up
QR codes look like the smallest part of a project but they are one of the few things you deliver that lives on paper for years. A few minutes of checking protects the client long after your work is done.
Top comments (0)