qr-api generates QR codes on demand. Send a GET request with any text, get back a ready-to-use PNG — no library to install, no encoder to maintain. $10/month, unlimited requests, no rate limits. Built with Node.js, Express, Postgres, deployed on Railway with Stripe billing. This is my first project ever — went from never using git to a live paid product in two sessions, mistakes and all. Would love feedback on pricing and positioning!
No reviews yetBe the first to leave a review for QR - API
Maker
📌
Hey everyone — maker here. This is my first product, and honestly my first time coding anything real. Happy to answer questions about the build, the stack, or the (many) mistakes I made getting this live. Would especially love feedback on whether $10/month feels right for what it does.
Report
Congrats on shipping your first product, that's genuinely cool. Quick question though — since you're generating QR codes server-side, what happens if my service gets a sudden spike of requests? Even with "no rate limits" there's gotta be some kind of scaling story behind the scenes to keep things reliable.
Report
Maker
@kaltal73447 Really good question, and honest answer: right now it's running as a single instance on Railway, no auto-scaling configured yet. QR generation itself is lightweight (milliseconds, tiny output), so it handles moderate traffic fine, but I haven't stress-tested a genuine sudden spike scenario yet — that's a fair gap to flag.
Given that, "no rate limits" describes the pricing model (no artificial cap on your usage) more than a guarantee of infinite scaling under load right now. If you're expecting significant spiky traffic, that's genuinely useful feedback for me to prioritize — horizontal scaling on Railway is doable, I just haven't needed to build it yet with the traffic I've had.
Appreciate you asking rather than just assuming — happy to follow up once I've actually load-tested it if that'd be useful to you.
Report
Maker
@kaltal73447 Update: went and added this right after you asked. Per-key rate limiting is live now (20 req/sec per key), so a sudden spike from one user can't affect anyone else's reliability. Still a single instance on Railway, no auto-scaling yet, but this closes the specific gap you flagged.
Tested it with a quick burst just now and it's working as expected. Appreciate the push — this is a better product because of it.
Report
Hit your API with a quick curl and got a clean PNG back in under a second, which is honestly all I ever wanted from a QR endpoint. Pricing feels fair for something I can just drop into a side project without babysitting a library. Congrats on shipping your first thing, it shows.
Report
Maker
@asiyekmeogipbc This means a lot, genuinely — thank you. "Drop it in and not babysit a library" is exactly the feeling I was going for, so hearing that it landed that way is great to hear.
And thanks for actually testing it rather than just reading the description — that's the first real "someone outside my own curl commands used this" moment for me, so I appreciate you taking the two seconds to try it.
Congrats on shipping your first product, that's genuinely cool. Quick question though — since you're generating QR codes server-side, what happens if my service gets a sudden spike of requests? Even with "no rate limits" there's gotta be some kind of scaling story behind the scenes to keep things reliable.
@kaltal73447 Really good question, and honest answer: right now it's running as a single instance on Railway, no auto-scaling configured yet. QR generation itself is lightweight (milliseconds, tiny output), so it handles moderate traffic fine, but I haven't stress-tested a genuine sudden spike scenario yet — that's a fair gap to flag.
Given that, "no rate limits" describes the pricing model (no artificial cap on your usage) more than a guarantee of infinite scaling under load right now. If you're expecting significant spiky traffic, that's genuinely useful feedback for me to prioritize — horizontal scaling on Railway is doable, I just haven't needed to build it yet with the traffic I've had.
Appreciate you asking rather than just assuming — happy to follow up once I've actually load-tested it if that'd be useful to you.
@kaltal73447 Update: went and added this right after you asked. Per-key rate limiting is live now (20 req/sec per key), so a sudden spike from one user can't affect anyone else's reliability. Still a single instance on Railway, no auto-scaling yet, but this closes the specific gap you flagged.
Tested it with a quick burst just now and it's working as expected. Appreciate the push — this is a better product because of it.
Hit your API with a quick curl and got a clean PNG back in under a second, which is honestly all I ever wanted from a QR endpoint. Pricing feels fair for something I can just drop into a side project without babysitting a library. Congrats on shipping your first thing, it shows.
@asiyekmeogipbc This means a lot, genuinely — thank you. "Drop it in and not babysit a library" is exactly the feeling I was going for, so hearing that it landed that way is great to hear.
And thanks for actually testing it rather than just reading the description — that's the first real "someone outside my own curl commands used this" moment for me, so I appreciate you taking the two seconds to try it.