QR Dynamics

About the Project

A printed QR code is final: once it is on a flyer, a poster or a package, the only way to change where it points is to reprint everything. QR Dynamics solves that with one level of indirection: the QR encodes a short URL (/r/<slug>) that redirects to a target you can change at any time.

The QR never contains the final URL, only the slug. The target lives in the database.

This is my first SaaS in production, built and operated end to end: product, design, code, database, payments, hosting and day-to-day operations.

What is live

• Dynamic redirection: change the target instantly, no reprint
• Visual styling: colors, module shapes, center logo, reusable brand kit, live preview
• Export to PNG, SVG and print-ready PDF
• Scan analytics: volume, device, country, last scan, non-blocking logging
• Conditional redirection and multi-link pages (/p/<slug>)
• Accounts and billing: Supabase authentication, Stripe subscriptions with webhooks
• Abuse handling: target URL checks through Safe Browsing, reporting, and a one-command kill switch on an abusive QR

Architecture

printed QR ──> /r/<slug> ──> Route Handler ──> 302 ──> target URL
                                  │
                                  └─ scan logged asynchronously

Scan logging goes through after(), so it never slows the redirection down. Data isolation is enforced both in code and by Postgres RLS policies.

Tech stack

Layer	Technology
Front + API	Next.js 16 (App Router), TypeScript
Database	Postgres via Drizzle ORM, versioned migrations
Auth & storage	Supabase
Payments	Stripe (subscriptions + webhooks)
QR rendering	qr-code-styling
Styling	Tailwind CSS 4

What I took away from it

Shipping a SaaS is not the same as shipping an application. The visible part was the shortest one: what takes time is billing, legal pages, the procedure when a QR is used for phishing, data purging, replaying a missed webhook. I wrote the operations runbook alongside the code, and that is the document I ended up using the most.