DEV Community: 王龙

I Built a Privacy-First QR Code Generator for Print-Ready Batch Workflows

王龙 — Tue, 30 Jun 2026 16:29:07 +0000

I recently built QRForge, a QR code generator focused less on tracking dashboards and more on print-ready workflows.

Most QR tools I found fell into two buckets: simple one-off generators, or dynamic QR platforms that route scans through their own tracking URLs. I wanted something more boring but useful: direct static QR codes, CSV batch generation, clear previews, and export files that are ready for labels, badges, packaging, or menus.

What I built

QRForge currently supports:

Static URL QR generation without signup
CSV upload for batch QR projects
First-row previews before export
Named PNG and SVG outputs
Manifest and error report files
PDF project summary
ZIP delivery for print workflows

The main idea is that a user should know what they are about to print before they generate hundreds of QR codes.

Why static QR codes?

Dynamic QR codes are useful, but they also introduce a dependency: the QR provider has to keep redirecting scans forever.

For printed materials, that tradeoff matters. A static QR code points directly to the destination URL. Once printed, it does not depend on my app staying online.

Stack

The project is built with:

Next.js
React
Cloudflare Workers
Stripe Checkout for one-time batch exports
Server-side ZIP generation for print packs

What I am still figuring out

The biggest question is positioning.

I am testing whether “Verified Print Pack” clearly communicates the value: preview the CSV, catch obvious problems, then export a print-ready bundle.

I’d love feedback from builders, designers, or anyone who has had to generate QR codes for real-world print materials.

Project: https://qrcodegenerator.page

I revived a small Mayan Tzolk'in calendar calculator and found real user demand

王龙 — Wed, 17 Jun 2026 13:54:27 +0000

I recently revived a small niche web tool I had left untouched for months:

Mayan Astrology Calculator

It converts a Gregorian birth date into a Mayan Tzolk'in calendar reading.

The Tzolk'in is a 260-day sacred calendar cycle made from 20 day signs and 13 tones. The tool calculates a user's Nawal day sign, Galactic Tone, and a short reflective interpretation.

Why I came back to it

The project had been quiet for a while, but Google Search Console showed that people were still finding it through search.

Queries like:

mayan astrology calculator
mayan zodiac sign calculator
mayan birth chart
mayan calendar calculator

were still getting impressions and clicks.

That was enough of a signal to make me revisit the project instead of abandoning it.

What I added

The original version was mostly a single calculator. I expanded it into a more complete static tool site:

A Mayan astrology birth date calculator
A result page with Nawal and Galactic Tone interpretation
Today's Mayan date
A compatibility calculator
A guide to the 20 Nawal day signs
A guide to the 13 Galactic Tones
SEO pages for related search intents
A simple waitlist for deeper personalized PDF reports

The site is built with Next.js and exported as a static site.

The interesting part: waitlist validation

I wanted to test whether this could become more than an ad-supported content site.

Instead of building payments, accounts, and PDF generation immediately, I added a lightweight waitlist CTA on the result page:

Want a deeper personalized Mayan birth chart report?

When users click it, they are invited to email us if they want early access.

This is intentionally higher friction than a normal email input. If someone actually opens their email client and sends their birth date and result, that is a stronger signal than a passive signup.

Within a short time, a couple of users actually emailed us with their birth dates and Mayan signatures.

That changed the question from:

"Is this just a fun niche calculator?"

to:

"Is there enough intent here to justify a paid personalized report?"

Why I did not build payments first

It would be tempting to add Stripe immediately.

But for a niche tool, I think that would be premature.

Before building a full payment flow, I want to validate:

Do users want deeper reports?
Would they pay for them?
What kind of report feels valuable?
Does a PDF report feel trustworthy enough?
What methodology explanation is needed?

So the next step is manual delivery: generate a few early-access PDF reports, send them to interested users, and ask for feedback.

Credibility matters

For a tool like this, trust is important.

The calculator part is deterministic: it converts a Gregorian date into a Tzolk'in signature.

The interpretation part is reflective. It is not scientific, medical, legal, or psychological advice.

For the PDF reports, I am adding:

A methodology section
A cultural note
A clear distinction between calculation and interpretation
A disclaimer
A sample report structure

I think this matters, especially when working with cultural or spiritual systems. The goal is to be useful and respectful, not to pretend to be an official authority.

Tech stack

The current stack is intentionally simple:

Next.js
Static export
Cloudflare Pages
Google Search Console
Google Analytics
Plain HTML/PDF templates for early report samples

No database yet. No payment integration yet. No account system.

The project is still in the validation stage.

What I learned

A few takeaways from this small experiment:

Old niche projects may still have search demand.
Google Search Console can reveal what users actually want.
A calculator can be more valuable than a blog post because the result is personal.
High-friction waitlists can be useful when you want stronger intent signals.
Paid product development should probably start manually before becoming automated.

Feedback welcome

I'd love feedback on the tool and the approach:

Mayan Astrology Calculator

Specifically:

Is the calculator flow clear?
Does the result page feel useful?
Would a paid PDF report make sense here?
How would you improve trust and credibility for a niche spiritual/calendar tool?

Thanks for reading.

I Built a Color-Memory Game with Next.js + Cloudflare: Making "Guess the Hue from Memory" Fun and Fair

王龙 — Tue, 09 Jun 2026 16:49:00 +0000

Hey everyone — I'm Potter, the solo developer behind Toon Tone.

💡 The Pitch in One Sentence
You are given the name of an iconic cartoon character and a specific part of them, but only a solid white block is displayed — you must drag the H/S/B (Hue, Saturation, Brightness) sliders to recreate the exact color from your memory. Five rounds, scored from 0–10 based on how close your color is to the target.

🎨 Why This Exists
We all think we perfectly "remember" pop culture colors — SpongeBob's signature yellow, Pikachu's rosy cheeks, or Mario's red cap.

But the moment you lose the visual context of the character's lines and shapes, and find yourself staring at a blank color picker, you realize a shocking truth: your visual memory and the actual RGB values are separated by a massive, humbling gulf. That exact psychological gap — the "I know I know this, but I'm completely guessing right now" feeling — is where the fun of Toon Tone lives.

🛠️ Two Core UX and Architectural Decisions
As a solo project, making a simple "guess the color" mechanic feel both intuitive and mathematically fair required some deep thought into the details:

HSB Sliders Instead of RGB In daily web development, we are used to dealing with RGB or Hex codes. However, in game design, RGB sliders are an absolute UX nightmare.

When the human brain wants to make a color "a bit more red" or "a lighter blue," we don’t naturally calculate how much to push the Red axis or subtract from the Green axis. We perceive color in a sequence: first we identify what the color is, then how vivid it is, and finally how bright it is.

Because of this, I strictly went with the HSB (Hue, Saturation, Brightness) model for the sliders:

Hue helps players anchor "which color" it actually is.

Saturation controls the vividness and intensity.

Brightness dictates the light and shadow.

Player feedback has proved this right: people instinctively set the hue first, then fine-tune the saturation and brightness, perfectly mirroring how the brain extracts visual memories.

Scoring System: Brutally Rigid sRGB Euclidean Distance In color science, using a perceptually uniform algorithm like CIEDE2000 is technically more accurate to how the human eye registers different spectrums. However, during early prototype testing, complex perceptual math just ended up confusing players. People would get frustrated, saying, "I feel like these two colors look almost identical, why did the game dock so many points?"

So, I made a very deliberate, hardcore engineering choice: calculating scores based strictly on standard sRGB space Euclidean distance.

While it might not be a perfect representation of human biology, it brings three massive wins to the table:

Brutal Fairness: There are no gray areas or hand-waving. Every unit of RGB deviation costs you points, pure and simple.

High Predictability: Players learn the exact "temperament" of the scoring model within two rounds.

Instant Performance: The calculation executes in roughly 0.0001ms, meaning zero rendering lag.

📈 Surprises & Insights from the Game
Content Cadence: I am currently keeping a rhythm of adding 1–2 new character colors every single Friday to steadily grow the pool.

The Charm of "Blind Color Guessing": Because the game renders only a solid color block without any surrounding illustrations or outlines, it acts as a pure, stripped-down test of isolated visual memory.

Polarized Difficulty: The hardest color to nail so far is SpongeBob's yellow (almost everyone oversaturates it and gets penalized heavily). On the flip side, the easiest to score high on is Pikachu (those two red cheeks are so deeply burned into collective human DNA that people's memory holds strong).

The Decay of Memory: The biggest predictor of a high score isn't whether someone has art training — it's whether they have watched or interacted with that specific show recently. "Nostalgia memory" decays at a wildly different rate than "recent recognition memory." This has actually shifted my weekly curation strategy; I now actively look out for what old anime are getting remakes or what's trending on streaming platforms to catch players at the peak of their cultural memory.

💻 The Ultra-Lean Stack (Next.js + Cloudflare Workers)
As an indie hacker, my top priority for this project was keeping maintenance costs at zero, rendering fast, and eliminating bloat. To achieve that, I built the entire architecture around the Cloudflare ecosystem:

Framework: Powered entirely by Next.js, which ensures a fantastic developer experience and clean code organization.

Compute & Deployment: Utilizing Cloudflare's official @cloudflare/next-on-pages, the entire Next.js project is deployed directly on Cloudflare Workers, taking advantage of ultra-low latency edge nodes globally.

Storage: Combined with Cloudflare KV / D1 to read and store core game configuration and data at maximum performance and near-zero cost.

Thanks to Cloudflare's edge network, the site loads incredibly fast across the globe. On a standard 4G mobile connection, the initial page load clocks in at around 200ms, delivering a frictionless, instant-play experience.

🎮 Test Your Own Color Memory!
The site is fully live in English with a clean, distraction-free UI. There are no signups, no paywalls, and no installations required — a full 5-round game takes less than 3 minutes.

Give it a spin here: https://toon-tone.net/?utm_sorce=https://dev.to/

Once you finish a run, drop a screenshot of your scorecard in the comments, or let me know: which character's color made you completely question your own memory?