Build a [QR code generator](/qr-code-generator) side project — real scope

You want to build a QR code generator side project, and the part you're picturing — the bit where a string of text turns into that little black-and-white square — is somewhere between one afternoon and one weekend of work. Pull qrcode.js off npm, wire it to a textarea and a canvas, ship. The hard truth anyone who has shipped a real QR product will tell you: the QR is not the product. The product is everything wrapped around it. We've built one. The actual scope, in evenings, is four to nine months.

This isn't a "scare you off building" piece. It's an honest-scope piece, so you can decide which version you actually want to ship. Three different products hide inside "QR code generator side project" — a static SPA, a dynamic redirect tool, and a multi-tenant SaaS. They have wildly different timelines. Picking the wrong one is the failure mode; so is starting the biggest one without realising it.

The "it's just a QR" trap#

The QR encoding library is a solved problem. A 25-year-old ISO standard (ISO/IEC 18004), three solid open-source libraries, zero remaining novelty in turning a URL into a barcode. qrcode.js, qr-code-styling, and Python's segno all encode correctly. Pick one in five minutes, glue it to an input field in an afternoon, and you're done with the thing the phrase "QR generator" actually names.

That's where most blog posts about building one stop, and where 80% of side-project QR generators on GitHub stop — a static page, an input, a download button. It works, nobody pays for it. If your goal is to learn QR encoding and ship something live, that's fine. Ship the SPA, move on — and once it's live, put a QR on the README pointing back to the demo, using the GitHub-targeted QR patterns so the link survives the inevitable repo rename.

If your goal looks like a business — dynamic links, scan tracking, customer accounts, branding, charging money — the QR is roughly 5% of the work. The other 95% is what nobody photographs for the launch tweet. If you want a worked example of where that 95% actually lives, the QR docs lay out the designer, the error-correction control, the redirect layer, and how scan tracking hangs off the same record — the headline parts of the "I'll build it in a weekend" plan that don't exist in qrcode.js.

What you're actually building, week by week#

The honest week budget for the dynamic/multi-tenant version. Numbers from our own build of Linked.Codes and from notes compared with other operators in the same niche.

QR encoding glue: 1 day. Library install, render to canvas, export PNG. No week-long version of this task exists. If it's taking longer, you're fighting framework setup, not QR encoding.

Style customisation: 3-5 days. Foreground/background colour, logo embed, custom eye shapes (the three corner squares), dot styles. qr-code-styling covers most of this; the work is plumbing controls and validating scans still resolve after a customer has cranked contrast in a way the spec doesn't allow.

PNG and SVG export at print-ready DPI: 2 days. Browser canvas is 96 DPI; a QR on a business card needs 300 DPI. SVG sidesteps resolution but introduces font-embedding pain if you've added a label.

At this point, a static-only SPA is feature-complete. Two weeks of evenings, done. Roughly 80% of side-project QR generators stop here, because the next jump is 10× the work.

Dynamic redirect: 2-4 weeks. The QR now encodes a URL on a redirect host you operate, not the customer's destination directly. You need a server, a database table mapping slug to destination, collision handling, click logging with timestamp and rough geolocation, and an admin UI to edit the destination after the QR has been printed.

Auth and accounts: 2-3 weeks. Email-and-password signup, login, password reset, sessions, account settings. The unhappy paths (reset emails to spam, sessions expired mid-edit) eat the time, not the happy path.

Multi-tenant data isolation: 2 weeks. Every query tenant-scoped. Every URL resolving to the right tenant. Permissions for sub-users. Statistically the phase that kills around 30% of solo SaaS attempts mid-build — multi-tenancy is where the architecture either survives the rewrite or gets quietly archived.

Custom-domain TLS: 1-2 weeks. If customers want their QR codes redirecting through their own domain — and most do, because the brand on the redirect host is a trust signal — you need automated cert issuance per tenant. Caddy's on-demand TLS or LetsEncrypt automation. Debugging cert issuance across DNS propagation and rate limits is genuinely fiddly.

Analytics: 2-3 weeks. Click ingest, aggregation, charts, date-range and slug filters. Building "a chart" is fast; building "a chart that doesn't fall over at 100k clicks" is slow. Pick a sensible storage strategy upfront.

Billing: 2 weeks. Stripe Checkout, webhooks, plan-change flows, dunning, refunds. The unhappy paths in payment flows are unforgiving.

Production hardening: 1-2 weeks. Monitoring, error alerting, daily backups, log retention, an actual restore test. Nobody enjoys this work; it's what separates a hobby project from something a stranger will pay for.

Add it up: 19 to 25 weeks of evenings, which calendars to four to nine months depending on how many evenings a week you can give it. That's the honest range. Anyone who says "I shipped my QR generator in two weeks" built the SPA-only version, lifted a starter kit, or is rounding aggressively.

The post-render iceberg#

Roughly half of the effort on a QR product happens after the QR has rendered correctly. You think you're done, you screenshot it, the bug reports start.

A short list of "after the QR renders" failures we've personally hit:

A customer's brand colour is too dark in both foreground and background. Contrast ratio sits below the threshold for reliable scanning. The QR renders, looks fine to humans, fails to scan in low light. You need a contrast check.

The customer pastes a 4 megapixel logo and demands it be embedded at 30% of the QR's area. Error correction at level H can absorb 30% damage — but not when concentrated in the dead centre across the timing patterns. You need a logo-coverage validator.

The customer prints the QR at 8mm wide on a tradeshow lanyard. Phones can't focus that close. You need a minimum-print-size warning tied to error-correction level.

The customer scans with an old Android, a new iPhone, and a Samsung in a low-light bathroom. Two work. The third files a ticket. You start owning a test rig of physical phones, or you stop sleeping on Sundays.

None of this is QR encoding. All of it ships as part of "a QR code generator". The encoding library handed it to you in five minutes; the product takes the rest of the year.

Static-vs-dynamic — pick this on day one#

The biggest decision happens before the first commit, and most people don't realise they're making it. Are you building static (input → PNG download, done) or dynamic (input → short URL on your redirect host → editable destination → click logging)?

Static is a two-week SPA. No server, no database, no auth, no billing. Customer types a URL, downloads a PNG, prints it. If they need to change the URL later, tough — they reprint. Most QR generators on the internet are this. Fine learning project, fine free tool. Unlikely to be a paid business.

Dynamic is a four-to-nine-month SaaS. Customer types a destination, your server allocates a short URL on a domain you operate, the QR encodes that short URL, and the customer edits the destination forever. You log every scan. This is the version with paying customers — and the version where you discover, partway through, that you weren't building a QR generator at all. You were building a redirect host with a barcode renderer attached.

Naming the project "QR generator" is what makes founders underestimate it. The honest name is "redirect host with a QR rendering on top". Once you've named it correctly, the scope becomes obvious — everything required to operate a small redirect host, plus a rendering library that takes one day. Our broader notes on why owning your link infrastructure is the actual product cover the same insight from the link-shortener side; it applies identically here. Once dynamic is on the table, why dynamic QR types should be the default walks the format-by-format picture.

Scope estimator — your version of this project#

Pick the features you'd ship. The estimator gives evening weeks, an opportunity-cost number at $40/h, and a verdict. Defaults are populated to a "real product" baseline — toggle items off to see how much faster the static-only version is.

The default checked set — basic generator, dynamic redirect, brand customisation — lands at 5 weeks, 50 hours, $2,000 of opportunity cost, and a verdict that you're in dynamic-but-single-tenant territory. Toggle on multi-tenant accounts, custom domain, analytics, and billing and you're at 16 weeks, 160 hours, $6,400 of unpaid time, and the verdict flips to full SaaS. That is the gap between the project you think you're starting and the product the market actually pays for.

What you're really building when it's a paid product#

In a paid QR product, the QR is not the value. The redirect host is. Customers pay every month so the URL on their printed materials keeps resolving, so they can change the destination without reprinting, so they can see who scanned and when, and so the redirect host carries a brand they trust enough to print on their packaging.

That last one is load-bearing. A QR pointing at bit.ly/xyz and a QR pointing at yourbrand.codes/menu do exactly the same thing technically. Commercially, they're different products. The first says "we use a tool". The second says "we own this surface". Customers will pay $30/month for the second and refuse $5/month for the first. The barcode is identical; the URL inside it is the entire business.

If "redirect host with a brand on it" sounds suspiciously like a link shortener, you've spotted the pattern. It is one. A QR generator with paying customers is, structurally, a branded link shortener with a barcode renderer attached. Most of the surface area we listed (auth, multi-tenancy, custom domains, billing) is identical to what you'd build for a link-shortener business.

The "I'll just self-host" trap#

The pitch: skip the SaaS layer, self-host on a cheap VPS, $5 a month. Three things will go wrong on roughly an 18-month cycle.

TLS auto-renewal will fail silently. Caddy or LetsEncrypt's auto-renewal is reliable until it isn't — a DNS provider rate-limits, a config gets edited, the cron job dies six weeks before the cert expires. You find out from a customer saying their QR redirect now shows a browser security warning. Three weeks of trust gone overnight.

The VPS will reboot for kernel updates and your service won't auto-start. Until you've tested cold-boot recovery, you don't have an auto-restarting service — you have a service that happens to be running.

The disk fills with logs, the database starts refusing writes, you don't notice because the marketing site still serves cached content. Three weeks of new signups silently fail.

The point isn't that self-hosting is a mistake — it can be a fine choice — but that the operational tax of running a redirect host is real and recurring, not a one-time setup cost.

The honest economics#

A QR generator product like the one above rents for $5-$30 per month per business, depending on what's bundled. Single-user with basic dynamic at the low end, multi-user with custom domains and analytics at the high end.

Math out break-even. Six months of evenings — 240 hours, $9,600 at $40/h opportunity cost — has to come back before you make a dollar of profit. At $20/customer/month with 30% net margin after Stripe and hosting, you need 1,600 customer-months just to break even. That's 65 customers for two years, or 130 customers for one year.

The conversation we keep having isn't "is the build worth doing?" — sometimes yes, sometimes no — but "did you know you were building a SaaS, not a generator?" Once you know, the rest follows. You can ship the static-only SPA and call it done. Or skip the redirect-host build entirely and rent a platform — the buy-vs-build cost math we already did for whitelabel SaaS lands the same way for QR. The zero-to-$5k-MRR math for a single tool is the natural follow-on if you go the buy route — the eighteen months you'd have spent building become eighteen months acquiring customers.

Library landscape — pick one, stop benchmarking#

Three libraries are worth your time. The rest are forks, demos, or abandoned.

qrcode.js (davidshimjs/qrcodejs original, broadly forked on npm). Oldest, smallest, most widely deployed. Pure JavaScript, browser or Node, exports canvas. Zero dependencies if you can live with raw output.

qr-code-styling. Modern. Rounded dots, custom eye shapes, gradient fills, centre-image embedding out of the box. What qrcode.js always becomes once you add style controls. Slightly heavier, worth it.

segno (Python). Best-in-class for server-side Python. SVG and PNG, supports micro-QR and structured-append.

Pick the one matching your stack, glue it in an afternoon, move on. The library is not where you make a meaningful product decision.

When the build is worth it anyway#

None of the above is an argument for not building. It's an argument for going in with the right expectations.

It's worth it if you want to learn how to ship a small SaaS from blank repo to first paying customer — the QR niche is one of the cleanest training grounds for that. It's also worth it if you have a specific niche customer (restaurant POS, church donations, tradeshow analytics) whose needs aren't covered by existing products.

It's not worth it if you want a generic QR generator and assumed it'd be a weekend project. The market is full of generic QR generators. You'll spend six months building a worse version of one that already exists. Rent the platform, brand it, and put the nine months into acquisition instead — where the margin lives.

FAQ#