How I Built QRPro (And What Broke Along the Way)

So you want to know how QRPro came to be? Fair enough. Pull up a chair.

It started simple. Very simple. First commit: basic QR code generator. You put in a URL, you get a QR code out. Riveting stuff. But that's where every tool starts — boring and functional, like a hammer before someone figures out you can also use it to open bottles.

The Boring Stuff That Actually Matters

After the basics, I added Google Analytics. I know, thrilling. But here's the thing: if you build something and don't know who's using it, you're just making assumptions in a void. So tracking went in. Then UTM tracking builder — because apparently marketers need hand-holding to build URLs with parameters. Fair enough. I built the tool so they stop asking me.

Then I tried something a bit more ambitious: a link shortener.

When Vercel Meets JSON (And Loses)

Link shortener seemed straightforward. Shorten a link, redirect when someone hits it. Easy.

Except it broke on Vercel.

The issue? I was using a JSON file as the database. Which works locally. Which works on a persistent server. But Vercel is serverless — every request spins up a fresh environment, and that JSON file? Poof. Gone. New request, new environment, empty database.

That's a fun one to debug at 2am.

Fix was straightforward once I figured it out: switch to SQLite. Persistent, file-based, works across function invocations. The link shortener came back to life, and I've been a little more careful about assumptions since then.

The Slow Grind of Polish

After the link shortener drama, it was time for the stuff that doesn't make headlines but makes a product usable:

• Batch QR generation (because making one at a time is for suckers)
• SEO basics — sitemap, robots.txt, meta tags (so Google doesn't ignore you)
• Share, print, clear, edit — the little verbs that make a tool feel like a tool

These aren't sexy. Nobody writes blog posts about their sitemap. But this is where a project goes from "proof of concept" to "something I'd actually let someone else use."

Getting Fancy

Once the foundation was solid, I started adding features that felt like actual value:

• Payment QR codes — because Venmo and PayPal QR codes should just work
• AI design style presets — classic, modern, vintage, minimal, galaxy, neon. Look, sometimes you want your QR code to look like it's from the future. Sometimes you want it to look like your grandma's cookbook. I gave options.
• Deep linking — #url, #wifi, and the whole gang. Makes it easier to share specific QR types without explaining what to do

Then I set up Ralph — that's my autonomous improvement loop. Every day, it looks at what's happening, makes tweaks, and keeps things moving without me micromanaging. Like a roomba, but for a web app.

The Details That Stick

Logo overlay was one of those "why didn't I think of this earlier" features. Companies want their QR codes to look like theirs. Slap a logo in the middle, boom — branded QR code.

And the agency landing page? That was for the folks who don't want to build their own QR codes — they want someone to do it for them. Service business, meet tool business.

The Long Game

Here's what I've learned: building in public is weird. You ship something, it breaks, you fix it, you ship more, something else breaks. The link shortener was down for a bit. Then it came back. Stabilized. Now it just works.

That's the goal. Not shipped, not launching — stabilized. The day something works so well you forget it exists? That's the win.

Anyway, that's QRPro. Still evolving, still breaking things occasionally, still getting better. If you need a QR code, check it out. And if you want to see what else I've been building, there's a whole blog over there where I occasionally write about this stuff.

— Wooderson