NFC / Linktree / Menu Builder Review
Purpose
Review the architecture, user experience, security, and reliability of NFC-triggered digital experiences: link-in-bio / linktree pages, QR code generators, restaurant/event menu builders, digital business card (vCard) flows, short-link redirectors, and dynamic profile pages optimized for mobile-first tap-to-open interactions.
When to use
- Reviewing a product where an NFC chip or QR code redirects to a profile, menu, or link list.
- Auditing a short-link or redirect service that backs NFC URL chips.
- Evaluating a drag-and-drop menu or profile builder and its generated output.
- Reviewing vCard/hCard generation or
.vcf download flows.
- Checking mobile-first landing pages intended for NFC tap users (often time-sensitive, low tolerance for load failures).
When not to use
- General marketing landing page review with no NFC/QR/short-link component.
- Backend API review with no mobile UX surface.
- Print-side NFC card design review — use
83-print-design-artifact-review for that.
Procedure
1. NFC URL routing
- Verify the NFC target URL is HTTPS — HTTP URLs may be blocked by Android/iOS browsers or trigger security warnings.
- Short-link resolution must be a single redirect (301 permanent or 302 temporary), not a chain of 3+ hops, which adds latency on mobile networks.
- Dynamic URLs (e.g.,
https://tap.example.com/c/abc123) must not expose internal database IDs; use short opaque tokens.
- Check that the redirect service handles high concurrency: NFC taps at an event can spike simultaneously.
- Verify that disabled or expired NFC cards redirect to a graceful fallback page, not a 404 or blank screen.
2. QR code generation and correctness
- QR code error correction level: minimum M (15% recovery); for cards likely to be scratched or printed small, use H (30%).
- QR payload must encode the final destination URL, not an intermediate redirect — unless the redirect is intentional for tracking.
- Generated QR images must be served as SVG (scalable) or PNG at ≥ 500 × 500 px for print use.
- Verify the QR can be decoded by at least two independent QR scanners before marking as production-ready.
- Check that special characters in URLs are percent-encoded inside the QR payload.
3. Profile / linktree page builder
- Builder output must generate valid, semantic HTML — verify no unclosed tags, duplicate IDs, or accessibility violations (buttons without labels, images without alt).
- Custom slugs/usernames must be sanitized: alphanumeric + hyphen only, length capped (e.g., 3–50 chars), reserved words blocked (
admin, api, static).
- Profile image uploads: validate MIME type server-side (not just file extension), enforce size limits (e.g., max 2 MB), strip EXIF data before storage.
- Link entries must be URL-validated server-side (
http:// or https:// scheme only) to prevent javascript: XSS payloads.
- Ordering/drag-and-drop: persisted sort order must use an optimistic-update pattern with a server confirmation; if the save fails, revert visually.
4. Restaurant/event menu builder
- Menu data model:
Category → Item → Variants → Modifiers. Verify the schema supports all required nesting levels.
- Multilingual menus: text fields must support Unicode fully; RTL scripts (Arabic, Hebrew) need
dir="rtl" on the container.
- Item availability toggles (sold out, seasonal) must propagate to the public menu page within seconds, not requiring a full publish cycle.
- Allergen/dietary flags (GF, vegan, nuts) must be editable per item and rendered prominently — legal risk if missing or incorrect.
- PDF export of menus: verify fonts are embedded and layout does not break at A4/Letter sizes.
5. vCard / digital business card
.vcf files must use vCard 3.0 or 4.0 format; verify with a validator before exposing the download endpoint.- Fields:
FN, TEL, EMAIL, URL, ORG, ADR — all values must be escaped per RFC 6350 (colons, semicolons, backslashes).
- Photo embedding in vCard must be Base64-encoded JPEG/PNG under ~100 KB — large photos cause iOS Contacts import failures.
- Download link should serve with
Content-Type: text/vcard and Content-Disposition: attachment; filename="name.vcf".
- Never store phone numbers or emails in the URL query string — use the vCard download endpoint directly.
6. Dynamic content and real-time updates
- If menu/profile content is edited while the NFC card is already deployed, the redirect must serve the updated content without requiring a new NFC chip reprogram.
- Cache headers on profile pages:
Cache-Control: no-store or very short TTL (< 60 s) for mutable content; longer TTL only for truly static assets (logos, fonts).
- CDN edge caching must not cache personalized or owner-edited pages by default.
7. Mobile-first performance
- First Contentful Paint target: < 1.5 s on a 4G connection.
- No render-blocking scripts on the initial tap landing page.
- Touch targets: buttons/links ≥ 44 × 44 px (Apple HIG) / 48 dp (Material).
- Avoid carousels or complex animations — users on NFC tap are in a brief attention window.
- Test on both iOS Safari and Android Chrome; WebKit and Blink differ on certain CSS behaviors.
8. Analytics and tracking
- UTM parameters appended to NFC redirect URLs for source attribution (
utm_source=nfc&utm_medium=card&utm_campaign=...).
- If analytics pixels are present, ensure consent is collected where required (GDPR/ePrivacy) before firing non-essential tracking.
- Short-link click counts must use server-side counters, not client-side events, to survive adblocker interference.
Checklist
NFC routing:
QR:
Profile / menu builder:
vCard:
Performance:
Common issues & anti-patterns
- HTTP NFC target URL: some Android browsers warn or block non-HTTPS; always use HTTPS.
- Sequential numeric IDs in short links:
tap.example.com/r/1001 exposes enumerable user profiles. Use random tokens.
javascript: in link fields: a builder that accepts arbitrary URLs without scheme validation is an XSS vector for other users who view the page.- QR at error correction L with small print size: the code becomes unreadable when the card scratches slightly.
- Long vCard photo: iOS Contacts silently fails to import vCards where the embedded image exceeds ~200 KB.
- Edge cache serving stale menu: a restaurant marks a dish as sold out but NFC users see it available for 24 hours due to aggressive CDN TTL.
- No fallback for disabled NFC chip: user gets a generic 404, with no context about the expired campaign.
- Non-UTF-8 encoding in QR payload: special characters (accented, CJK) in a URL break scan on some readers.
Required output
Return a structured report with:
- Summary: pass / needs fixes / blocked, primary risk (UX, security, data).
- Evidence: specific file or URL path and line references for each finding.
- Findings table: severity, category, description, remediation.
- Mobile UX assessment: performance and touch-target status.
- NFC/QR integrity check: redirect chain, error correction, scan test result.
- Next handoff: end-to-end physical tap test on real NFC hardware before launch.
Safety
- Never encode real customer PII (home address, unmasked phone) in QR payloads used for review examples.
- Do not reprogram or write to physical NFC chips during a code review.
- Flag any URL scheme injection (
javascript:, data:) in link fields as high severity.
- If allergen labels are missing in a menu builder serving food-service customers, flag as high (legal risk).