Tony Lily Hoang

2.Why I Removed the QR Code API

Why I moved QR code generation from a server API to the browser and ended up with a faster, cheaper, and more private product.

Published at

25 Aug 2026


Why I Built the API

When I first started building QR-gen.org, I had a QR code API behind the website.

At that time, I was learning Spring Boot and Render, so I wanted to see if I could build an API and actually use it in a real project.

Instead of just following tutorials and building something that would never be used, I thought it would be more interesting to build something for my own website.

So I built the API, connected it to the website, and it worked.

Whenever someone wanted to create a QR code, the website would send the information to my API, the server would generate the QR code, and then send it back to the browser.

At the time, I was pretty happy with it. I had built an API, hosted it, and actually had a website using it.

It Worked, But Something Felt Wrong

The API worked fine, but I started noticing a small problem.

Every time I generated a QR code, there was a small delay. The website had to send the information to the server, wait for the server to generate the QR code, and then send the result back to the browser.

The delay wasn't huge, but I could feel it every time I generated a QR code.

And that made me start thinking about the way I had built it.

Creating a QR code doesn't require some huge amount of computing power. It's a relatively small task that a user's device can handle by itself.

So I started asking myself a simple question.

Why am I sending this to a server at all?

Why Does a QR Code Need a Server?

The more I thought about it, the less sense the API made to me.

Generating a QR code isn't a task that needs a powerful server. The user's own computer or phone is already capable of doing it.

So instead of sending the data from the browser to my server and then waiting for the result to come back, I could just generate the QR code directly on the user's device.

That would remove the network request completely.

It would also mean that the information used to create the QR code wouldn't need to leave the user's device.

And there was another benefit that I hadn't really thought about at first.

If the QR code could be generated entirely in the browser, the website wouldn't need the API server anymore.

That meant I could save the roughly $8 I was paying every month to host it on Render.

So I thought, why not just try it?

I Moved It Into the Browser

So I decided to try it.

I changed the QR code generator so that everything happened directly in the browser instead of sending the data to my API.

The browser would take the information, generate the QR code, and show it to the user immediately.

And it worked.

There was no API request anymore, so there was no need to wait for a server to respond before seeing the QR code.

The whole process felt much more natural. You enter your information, and the QR code appears right there.

I didn't need to keep a server running just to generate something that the user's own device could already generate.

At that point, I knew I didn't need the API anymore.

What I Got From Removing the API

Removing the API gave me more than just a slightly faster QR code generator.

First, the QR code could be generated immediately in the browser without waiting for a server response.

It also meant that the generator could work without an internet connection. Once the website itself was available, the actual QR code generation didn't need to send anything to my server.

That was also better for privacy. The information someone enters to create a QR code doesn't need to leave their device just to generate the QR code.

And, of course, I didn't need to keep paying for the API server anymore.

I was saving about $8 every month just by removing something that wasn't really necessary in the first place.

The funny thing is that the final version was actually simpler than the version I started with.

Sometimes Less Is Better

Looking back, I don't think building the API was a bad decision. At the time, I was learning Spring Boot and Render, and building it taught me a lot.

But I also learned that just because I can build something doesn't mean I need to keep it.

When I started QRCodeChicken, I wanted to build something simple and easy to use. Removing the API actually brought the architecture closer to that idea.

The browser could do the job, the user didn't have to wait for a server, their information didn't need to leave their device, and I didn't have to pay for another server.

Sometimes when building software, we think that adding more things will make the product better.

But sometimes the better solution is to remove something that was never needed in the first place.